BTRFS Support?
-
Hi guys, I was wondering if there was anyway to get the “single disk - resizable” option to work for btrfs based partitions. I’ve tested with whole disks, ie; mkfs.btrfs /dev/sda, as well as just partitions, ie; mkfs.btrfs /dev/sda1 and both times I get a “unknown partition” error.
Using the other “not resizable” and DD options I can get an image. But they take an hour to run. Running a test on a similarly built ext4 based partition, an image takes about 1 minute and is considerably smaller in size.
I’m pretty new to FOG management, so maybe there is an advanced option I can pass along in the web gui for btrfs based disks? Let me know if there is any type of info I can pass along that would help. Thanks!
-
When working on building the /dev/sda1 partition while using the mkfs.btrfs function, have you already created the partition table? If you did create the table, did you makes sure the partition table is recognized by the kernel by either running the
partprobe /dev/sda1or restarting the client?I know the resizable option is not possible, right now, for the btrfs filesystem type, but at the least the kernel and init’s should recognize btrfs as a valid type.
-
Yes, I had used fdisk to create a partition for the btrfs FS. The layout was like this --> sda1(7G)btrfs and sda2(1G)swap. I’m little confused on the partprobe part you mention. The test machine was a working and booting Arch Linux installation. So I guess yeah, the kernel can boot the FS just fine. Is there something else I’m missing there?
One thing I have noticed between my ext4 and btrfs test machines is when I go into the “Client System Information” option and select “Partition Information,” the ext4 system shows ext4 under the File system whereas it is blank when checking the btrfs system.
Also, I’ve noticed when trying to run the “multiple partitions - single disk” option for upload on the btrfs system, I get scripting loops that seem to error finding any valid partition. I was able to grab somewhat of a screenshot for reference. Possible a scripting error?
-
Sounds like we’ve had this for quite some time: https://forums.fogproject.org/topic/4580/add-btrfs-support
I never had the time to test BTRFS but to me it sounds as if it is broken. Anyone ever had this working?
Thanks for the screenshot. Looks like there is something major going wrong because /proc/cpuinfo is also missing… Sounds like the proc filesystem is not working on your machine. Weird! Do you see other errors before that??
-
The /proc errors was an attempt to minimize the information on the kernel. It should now be fixed.
-
I’m willing to be a tester if there is anything I can do. Currently the errors fly by in such quantity and speed I couldn’t snap screenshots fast enough so I made a video. I hope it helps.
https://www.youtube.com/watch?v=hJ_PtYl8NbY
Ultimately, partclone keeps erroring out and looping without ever ending.
-
Also, I noticed in an older btrfs post, blkid was asked for so here it is along with some other stuff.
blkid /dev/sda
/dev/sda: PTUUID=“a3b0e07d” PTTYPE=“dos”blkid
/dev/sda1: UUID=“324315dc-1403-4b4c-b162-149a6aaf927e” UUID_SUB=“c0639c9f-55f8-4e69-9568-77b62da7007b” TYPE=“btrfs” PARTUUID=“a3b0e07d-01”
/dev/sda2: UUID=“bc5af140-adb4-4261-b85d-cf27ed79e0a6” TYPE=“swap” PARTUUID=“a3b0e07d-02”lsblk /dev/sda
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 8G 0 disk
|-sda1 8:1 0 7G 0 part /
`-sda2 8:2 0 1023M 0 part [SWAP]fdisk -l /dev/sda
Disk /dev/sda: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa3b0e07dDevice Boot Start End Sectors Size Id Type
/dev/sda1 2048 14682111 14680064 7G 83 Linux
/dev/sda2 14682112 16777215 2095104 1023M 82 Linux swap / Solaris -
Which version of FOG do you use, by the way? Tom said he fixed the proc-errors. Did you update to the latest version and try again? Do you still see the same errors?
Tom:
I know the resizable option is not possible, right now, for the btrfs filesystem type
Why is this? Can we fix it?
-
I’m running Fog v1.2.0 on Ubuntu 14.04. I believe that is the latest from the sourceforge downloads.
-
I’m an idiot guys, I apologize. There is still an issue, but the video and error messages are no longer relevant. For some reason my /images directory got deleted, I think because I was changing my image names around. I was digging in the logs and caught it. I re-created the image and was able to pull a BTRFS image using the mulitple disk option again.
My original question still exists though, using the DD or multiple methods, the images take a long time. Using the multiple partition method grabs the partition using “raw.” Is there anyway to grab a btrfs partition so that partclone is FS aware? Like ext4 is done currently?
-
Right now no. I can take a look, but please understand I work for a school district, who just started back up for the school year. Right now i’m just busy.
-
Thanks Tom, I appreciate you taking a look. This isn’t time sensitive, just a wish list item I guess. Let me know if there is any testing I can do to help out with.
-
initial btrfs support should now be added. Just know that it, for now, will not be supported for “resizable” but for the non-resizable images it “should” work properly I hope.
-
Awesome Tom! Any idea on the next proper release that will include it?
-
@baggar11 What version of FOG are you running right now?
The next release “proper” that will have it is the one I’ve been working towards for over a year now. 1.3.0. I do not know when this will release, but it should have the necessary support you’re needing.
That said, you do NOT have to wait for 1.3.0 to release in order to try it. I understand the hesitation of updating to a “development” version of FOG, but I also can’t fix things in the development if I don’t have people testing it.
While it’s not recommended for people to run FOG in a “production” environment when operating with the development versions, I find it highly unrealistic in testing. I say this because the only “real” way to find out about problems is to put the thing you’re trying to “test” in to real situations it will be facing.
If you want to just see if things will work you (can/should?) make a test environment if possible and test on that.
Here’s instructions on upgrading to trunk.
Install/Upgrade to trunk -
Thanks Tom. I just got around to building up a Fog Trunk based installation. BTRFS file systems are recognized now and take much less time. Thanks!
A couple things I’ve noticed though.
- On installation, the apache config points to /var/www, which on ubuntu 14.04 is now /var/www/html. The v1.2.0 installation didn’t seem to do this.
- Under images, there is no “size on server” listed. That was kind of handy to see. Especially since there is a compression setting for images now.
- Testing an ext4 based system, I get a kernel panic when I try to run a Full or Quick registration.
-
@baggar11 probably sometime this fall… hopefully lol.
-
I’ve decided to solve this thread. The original issue is corrected for and seemingly operational now in trunk.
To add on, I’m currently imaging an arch64 system not only with EXT4 filesystems, but also in GPT format. So I’m not seeing problems that I would expect. I’m just guessing the ext4fs you’re seeing issues with may have a bad hdd potentially?
-
I’ll start a new thread about the ext4 issues on trunk. I’ll poke around a little bit more. I doubt the HD is going bad though, all of my test machines and FOG server are virtual machines.
-
@Uncle-Frank I don’t know how to do resize to the btrfs. To my understanding, btrfs can be expanded, but not shrunk. Even if that’s not true, I know we don’t have the utilities to do a volume resize.
For example, ext resize requires shrinking by first adjusting the volume size, then adjusting the sectors for the partition layout. Same premise happens for ntfs. I don’t know that btrfs has a similar tool, and even if it does, i’m pretty sure it’s not currently baked into the inits.