BTRFS mkinitcpio hook

hunterthomson · 2010-06-15 05:34:11

oops double post...

Well let me take this space to say thank you for all you hard work and engineering. I am going to try this out now instead of waiting for 2.6.34.

I'll let you know how it goes.

-----------
EDIT:
Well, btrfs-progs-git fails to build so I guess I'll just wait. It's only going to get better anyway Thanks again.

Well nevermide I got it to build by adding #include <sys/stat.h> to btrfsck.c
http://www.mail-archive.com/linux-btrfs … 05156.html

Last edited by hunterthomson (2010-06-15 06:32:02)

hunterthomson · 2010-06-16 01:56:17

Okay, all up and running. A quick note, I am using a Intel G2 SSD 80GB and without noatime,nodiratime in my fstab and without elevator=deadline in my GRUB menu.lst my system was almost unusable i.e. it could not play flash video and could not at all play netflix in Win7 VirtualBox. However, with them everything works fine. Also, with the compress flag my disk usage went form 32GB to 28GB. However, 20GB is a full VirtualBox HardDisk for the Win7. It doesn't seem like it can compress a .vdi image, ya nope, I just copied over a 12GB .vdi and it takes up 12GB of space on the compress btrfs partition.

One question though. What is the safe way to rm -rf the old / root partition?
I just want to make sure I don't trash my system.

---------------------

EDIT: Well never mind. Btrfs is crazy slow at multi-tasking. Which makes it unusable for me. I have a i7 Quad as you can see in my sig, and the btrfs-worker-1 and friends are only one thread, so they can only use one of my 8 logical cores. What happens is if something is happening that is vary disk intensive, like copying a large file to the btrfs partition, the btrfs-worker uses 100% of it's 1 core and then it can't do anything ells. Like lets say I was copying a large file to the btrfs partition; Then I try to start a new shell.... it takes like 1-3 min's before it will open the new shell. This is just not workable for me. Which sucks I liked the compression and role-back but the whole btrfs-worker stuff needs to be fixed before it can be used as a /root partition. There were many times when there was excessive lag do to btrfs. So, I moved back to ext4. I think I'll ask the btrfs guys what the deal is.

Or am I just doing something wrong?

Last edited by hunterthomson (2010-06-16 09:25:23)

extofme · 2010-06-18 01:36:08

hunterthomson wrote:

Okay, all up and running. A quick note, I am using a Intel G2 SSD 80GB and without noatime,nodiratime in my fstab and without elevator=deadline in my GRUB menu.lst my system was almost unusable i.e. it could not play flash video and could not at all play netflix in Win7 VirtualBox. However, with them everything works fine. Also, with the compress flag my disk usage went form 32GB to 28GB. However, 20GB is a full VirtualBox HardDisk for the Win7. It doesn't seem like it can compress a .vdi image, ya nope, I just copied over a 12GB .vdi and it takes up 12GB of space on the compress btrfs partition.
One question though. What is the safe way to rm -rf the old / root partition?
I just want to make sure I don't trash my system.
---------------------
EDIT: Well never mind. Btrfs is crazy slow at multi-tasking. Which makes it unusable for me. I have a i7 Quad as you can see in my sig, and the btrfs-worker-1 and friends are only one thread, so they can only use one of my 8 logical cores. What happens is if something is happening that is vary disk intensive, like copying a large file to the btrfs partition, the btrfs-worker uses 100% of it's 1 core and then it can't do anything ells. Like lets say I was copying a large file to the btrfs partition; Then I try to start a new shell.... it takes like 1-3 min's before it will open the new shell. This is just not workable for me. Which sucks I liked the compression and role-back but the whole btrfs-worker stuff needs to be fixed before it can be used as a /root partition. There were many times when there was excessive lag do to btrfs. So, I moved back to ext4. I think I'll ask the btrfs guys what the deal is.
Or am I just doing something wrong?

i'm really not sure why you are experiencing problems like not playing flash and whatnot... i run btrfs on my laptop, 1.8ghz t43 thinkpad, without any problems. i mount "defaults,noatime". i have a quad core phenom upstairs but i havent set it up with btrfs quite yet, so i'm not sure about multicore setups, but everything works perfectly fine on the lappy, flash and all. every now and again i get a little lag but nothing beyond a second or two, and i mostly attributed this to the fact that arch isn't running 2.6.34 yet, and i've put my laptop thru a lot while testing the hook :-/.

i don't recommend using the compress mount option yet. zlib is too processor heavy, and could be contributing to your problems; wait for another algo to be available like LZMA(2). also, filesystem level compression is not a magic bullet for files that are already in a compressed format like images/movies, and can likely increase the size in some cases. it uses the same algorithms as userspace compression tools, it's just done for you transparently at the kernel level.

additionally, you may be experiencing performance problems by mounting your subvolumes with "compress" for the first time. IIRC, btrfs uses a lazy compression method; if you mount a regularly uncompressed subvolume with the compress option, it just compresses files as it goes, as it encounters them. so if you have a huge filesystem thats normally uncompressed, mounting it with compress could be spending CPU time compressing everything it reads until it doesn't encounter anymore uncompressed files. it can read uncompressed/compressed files at anytime, with or without the compress option; the option just dictates how to handle the files when changed (and maybe even read, im not sure there).

this is the case with the .vdi image; it is likely already compressed and compression at the filesystem level is only wasting CPU, and possibly even slightly inflating the file size. try gz compressing a file 100 times; there is a limit, and at some point (sooner) the file size will go up.

to rm -rf the old / do this:

# mount -o subvol=. <btrfs_device> /mnt
# <now rm -rf anything in /mnt that doesn't start with __ (two underscores)>
# <it might take awhile...>

i really hate that this is the only way; make some noise on these threads:

http://www.mail-archive.com/linux-btrfs … 04964.html
http://www.mail-archive.com/linux-btrfs … 04968.html

no developers have answered me; i'm not sure why. meh.

having said all that, i think many of your problems are due to running .33 and not .34+ kernel. i'm not sure the holdup on the kernel... i thought arch would have it by now. many of the issues you describe i remember coming up on the list and have been addressed (especially threading issues) awhile ago. what do you mean by 'lockups' regarding opening a shell? i have not experienced this, my system has never become nearly that unresponsive; you may have other things amiss.

also, i don't know how much luck you'll have on the list about it; just the other day this message came thru:

"2.6.34 is far too old."

if you really can't make it work, i'd say just wait for the bump to .34 or .35 and it'll be fine.

C Anthony

hunterthomson · 2010-06-18 06:12:09

Right on, I'll try it again when .34 is out. I'll also try it without the compress flag. In retrospect, if CPU was a problem for me then disabling compress should have been the first thing I tried. Okay ya, it makes sens that the already compressed files would not get compressed anymore. It was nice having 4 more GB but I guess they may have been a error with the df reporting but from what I read the df reporting errors are seen more in like a RAID setup.

Just to clarity. I mounted the partition in the live ArchUSB with mount -o compress /dev/sda2 /mnt/sda2 and then copied the files to it. So everything should have been compressed from the git go.

Last edited by hunterthomson (2010-06-18 06:21:41)

falconindy · 2010-06-20 17:29:53

Set this up yesterday in my "downgrade" from 64-32bit. One simple note that might help some other people:

- When you create the __active subvolume, do yourself a favor and make sure to 'chmod 755' on it. This'll save you endless headaches and holes in your walls.

Also, a concern... snapshots, while extremely cool, have a fairly glaring hole in Arch. Consider the following:

* You have a separate /boot partition because you're using btrfs
* kernels are kept on /boot
* Arch doesn't keep old kernels

I made a snapshot when I finished my install. For grins, I added some more stuff, and then rebooted, mounting the snapshot as the root instead of __active. It works flawlessly -- very cool. Problem: as soon as my kernel changes, this snapshot is no longer bootable because the kernel modules that are available on the snapshot no longer match the available kernel images on /boot.

I'm not really sure of a reasonable strategy to deal with this. The idea of keeping old kernels around in some arbitrary fashion doesn't sit well with me. Is the "solution" just to snapshot after each kernel install and resolve to treating older snapshots as being akin to backups and not bootable snapshots?

extofme · 2010-06-21 03:49:49

2.6.34 has moved to [core]. i will be pushing an update soon to make use of the new features in .34. it will speed up boot times, among other efficiency improvements. it will make use of .34's ability to list subvolumes, and set a new default.

falconindy wrote:

Set this up yesterday in my "downgrade" from 64-32bit. One simple note that might help some other people:
- When you create the __active subvolume, do yourself a favor and make sure to 'chmod 755' on it. This'll save you endless headaches and holes in your walls.

by default, subvolumes are created with mode 700; i presume to protect them from being changed by anyone but root. it shouldn't cause any problems at all though... what was the issue you had? the hook doesn't do this.

falconindy wrote:

Also, a concern... snapshots, while extremely cool, have a fairly glaring hole in Arch. Consider the following:
* You have a separate /boot partition because you're using btrfs
* kernels are kept on /boot
* Arch doesn't keep old kernels
I made a snapshot when I finished my install. For grins, I added some more stuff, and then rebooted, mounting the snapshot as the root instead of __active. It works flawlessly -- very cool. Problem: as soon as my kernel changes, this snapshot is no longer bootable because the kernel modules that are available on the snapshot no longer match the available kernel images on /boot.
I'm not really sure of a reasonable strategy to deal with this. The idea of keeping old kernels around in some arbitrary fashion doesn't sit well with me. Is the "solution" just to snapshot after each kernel install and resolve to treating older snapshots as being akin to backups and not bootable snapshots?

indeed. this is one of the gotchas i pointed out of the first page i think, but i can't find it now; bleh, maybe it was a different thread.

the 'best' solution is to wait for grub2 to support btrfs, and complain until Arch moves to grub2... which i'd expect must/will happen eventually.

a more immediate solution is to use the tool i'm working on and have it back up the kernel in some way. the tool is used to manage snapshots, name them appropriately, and place them in the correct place when created. it mounts the default subvolume somewhere in /var (to gain access to the subroot structure __active/__rollback/__snapshot) and can make snapshots of __active to __snapshot/XX-YY-ZZ (anything in __snapshot is selectable by the hook), or it can 'promote' __rollback to __active. i see the /boot problem being solved in one of 2 kludgy ways:

1) when a __snapshot is added, the tool copies the current kernel+initramfs and names them to correspond to their respective snapshot. menu.lst could be appended with a new entry, and parameters could be added to the kernel boot line to automatically tell the hook which snapshot it should use; i believe this is similar to how fedora handles rollback.

2) before a __snapshot is added, the tool rsync's /boot to __active/boot. when the user chooses a snapshot, the hook reads the fstab and mounts /boot, moves everything to backup files (say kernel26.img.bak), and copies everything from __snapshot/XX-YY-ZZ/boot to /boot. the hook then reboots the system to let the older kernel/initramfs start up.

1 is probably simpler/cleaner/easier to implement, and seems the best solution. 2 is more complete, and is closer to being an actual rollback, but it would likely require a reboot anytime a snapshot is used. ideas?

also, you said this:

falconindy wrote:

For grins, I added some more stuff, and then rebooted, mounting the snapshot as the root instead of __active. It works flawlessly -- very cool.

i wanted to clarify that the hook does _not_ work like this. the hook never mounts snapshots residing in __snapshot directly; it makes yet another snapshot, to __rollback, and mounts that instead. this means your snapshots stay clean and are never modified unless you do it manually yourself. it also makes it easy to promote __rollback to __active.

although, i have considered adding the ability to do this. i was thinking of making another folder, say __system, that would contain directly bootable snapshots, ie. they would remain in whatever shape you left them in after running them. the problem is that i don't see a use case for this... you would essentially have many different systems that would need to be maintained independently, and you could only ever run one at a time (vs. running systems in a VM or container). why? is this something that interests you or anyone else? i don't see a reason for it but i'm open to ideas.

C Anthony

falconindy · 2010-06-21 04:50:47

extofme wrote:

by default, subvolumes are created with mode 700; i presume to protect them from being changed by anyone but root. it shouldn't cause any problems at all though... what was the issue you had? the hook doesn't do this.

Logging in as a user other than root failed because I had no execute, let alone read privileges on /. Couldn't even 'su - foo'. Found the hint on a Gentoo thread after I pulled most of my hair out over what I knew was going to be something silly.

extofme wrote:

indeed. this is one of the gotchas i pointed out of the first page i think, but i can't find it now; bleh, maybe it was a different thread.
the 'best' solution is to wait for grub2 to support btrfs, and complain until Arch moves to grub2... which i'd expect must/will happen eventually.

If it hasn't happened yet, then I presume that it's because they're waiting for some elegant solution to materialize (or at least for btrfs to go stable so that there's more pressure to get 'er done). There's issues with the typical method Grub uses to identify volumes with stat(2) when used on btrfs volumes:

http://www.mail-archive.com/linux-btrfs … 02875.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540786

I'm, personally, not looking forward to using Grub2. I'd not complain if Arch stuck with Grub until something changed elsewhere that caused it to become unusable.

extofme wrote:

a more immediate solution is to use the tool i'm working on and have it back up the kernel in some way. the tool is used to manage snapshots, name them appropriately, and place them in the correct place when created. it mounts the default subvolume somewhere in /var (to gain access to the subroot structure __active/__rollback/__snapshot) and can make snapshots of __active to __snapshot/XX-YY-ZZ (anything in __snapshot is selectable by the hook), or it can 'promote' __rollback to __active. i see the /boot problem being solved in one of 2 kludgy ways:
1) when a __snapshot is added, the tool copies the current kernel+initramfs and names them to correspond to their respective snapshot. menu.lst could be appended with a new entry, and parameters could be added to the kernel boot line to automatically tell the hook which snapshot it should use; i believe this is similar to how fedora handles rollback.
2) before a __snapshot is added, the tool rsync's /boot to __active/boot. when the user chooses a snapshot, the hook reads the fstab and mounts /boot, moves everything to backup files (say kernel26.img.bak), and copies everything from __snapshot/XX-YY-ZZ/boot to /boot. the hook then reboots the system to let the older kernel/initramfs start up.
1 is probably simpler/cleaner/easier to implement, and seems the best solution. 2 is more complete, and is closer to being an actual rollback, but it would likely require a reboot anytime a snapshot is used. ideas?

I like the idea of creating a /boot within the snapshot and copying the kernel there -- this seems like a clean solution. I'm not familiar with early userspace to know if this is viable, but could the kernel on the __snapshot/xx-yy-zzzz/boot be mounted instead of the one defined by the grub kernel line? This would be pretty slick. You'd have to be cognizant of the real /boot being mounted over it once the system fully boots, but that's really a non issue.

You might consider using kexec to swap kernels. It's still sort of a reboot, but I think it would be a lot easier to manage. Mount the __snapshot, snap it to __rollback, and kexec __rollback/boot/vmlinuz26. You can specify a new kernel cmdline with it to set rootflags=subvol=__rollback.

I'm a bit wary of modifying menu.lst programatically. This smells a lot like Grub2's black box scripts to build grub.cfg. The use of kexec, I believe, would make this a non-necessity.

extofme wrote:

i wanted to clarify that the hook does _not_ work like this. the hook never mounts snapshots residing in __snapshot directly; it makes yet another snapshot, to __rollback, and mounts that instead. this means your snapshots stay clean and are never modified unless you do it manually yourself. it also makes it easy to promote __rollback to __active.
although, i have considered adding the ability to do this. i was thinking of making another folder, say __system, that would contain directly bootable snapshots, ie. they would remain in whatever shape you left them in after running them. the problem is that i don't see a use case for this... you would essentially have many different systems that would need to be maintained independently, and you could only ever run one at a time (vs. running systems in a VM or container). why? is this something that interests you or anyone else? i don't see a reason for it but i'm open to ideas.
C Anthony

Oh yeah, I did this manually just for kicks. Keeping the snap clean is definitely important. I was just having fun with the same drive mounted multiple times at each subvolume. I have no use case for when this would be warranted.

extofme · 2010-06-22 06:50:14

falconindy wrote:

Logging in as a user other than root failed because I had no execute, let alone read privileges on /. Couldn't even 'su - foo'. Found the hint on a Gentoo thread after I pulled most of my hair out over what I knew was going to be something silly.

ah i see, i thought i tried this but i must not have. plus, new subvol is created with mode 700, a snapshot is created with mode 555, weird ( `ls -al` shows '.' as being mode 555 too). ill put a check in for that.

falconindy wrote:

If it hasn't happened yet, then I presume that it's because they're waiting for some elegant solution to materialize (or at least for btrfs to go stable so that there's more pressure to get 'er done). There's issues with the typical method Grub uses to identify volumes with stat(2) when used on btrfs volumes:
http://www.mail-archive.com/linux-btrfs … 02875.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540786
I'm, personally, not looking forward to using Grub2. I'd not complain if Arch stuck with Grub until something changed elsewhere that caused it to become unusable.

nice i hadn't read much about grub2 development + btrfs. i wonder if there are any other blockers for btrfs implementation. although i haven't used grub2 all that much, i do want more power and flexibility from a bootloader.

falconindy wrote:

I like the idea of creating a /boot within the snapshot and copying the kernel there -- this seems like a clean solution. I'm not familiar with early userspace to know if this is viable, but could the kernel on the __snapshot/xx-yy-zzzz/boot be mounted instead of the one defined by the grub kernel line? This would be pretty slick. You'd have to be cognizant of the real /boot being mounted over it once the system fully boots, but that's really a non issue.
You might consider using kexec to swap kernels. It's still sort of a reboot, but I think it would be a lot easier to manage. Mount the __snapshot, snap it to __rollback, and kexec __rollback/boot/vmlinuz26. You can specify a new kernel cmdline with it to set rootflags=subvol=__rollback.
I'm a bit wary of modifying menu.lst programatically. This smells a lot like Grub2's black box scripts to build grub.cfg. The use of kexec, I believe, would make this a non-necessity.

i'm really not sure about the rules of hotswapping. i haven't read about kexec in awhile... but this all sounds neat so i'll have to do some research. maybe others will chime in with more knowledge?

i could probably implement both ways, and create a config file. we'll see how much time i put in...

C Anthony

hunterthomson · 2010-06-30 11:00:47

Well, I learned the joys of qemu-kvm. Qcow2 compression and overlay images saved my life. With this solution I no longer need a bunch of 20GB .vdi images for every VirtualBox VM I need running. With qcow2 compression I can get the 16GB(on-disk) base install of Server2008 down to 6.6GB and a base install of CentOS down to 871MB. Then, with the use of overlay images I can run as many Server2008 and CentOS VM's off of toughs base images as I want. Hell I was running 5 Server2008 and 3 CentOS server and it only took up 13GB(on-disk) total. SO, in short I no longer need file-system compression..... No, now my bottle neck is 4GB of RAM. However, KSM helps out a whole lot with that too

So, when you put out the new mkitcpio hook I'll give btrfs another go and I am sure I'll have better luck with no compression.

I'd like to put my vote in for Option #1
Just make a copy of the current kernel+initramfs and append a new entry in menu.lst

I have no qualm with editing memu.lst files. If any thing goes wrong it is easy enough to just hit "e" and edit the boot line.

The problem I see it that ether of the 3 solutions mentioned seem costly. I mean there is no reason to make a copy of the kernel+initramfs "every" snapshot. How would it go about checking to see if a kernel copy was needed, just uname -r ? It would be safer to do a sha1sum but time consuming.

You know what would be cool would be to have a new grub menu.lst entry made for every snapshot. If a new kernel+initramfs is needed then call that and if not then just link to the currnet one with need boot flags to roll back to the snapshot. It would also be cool if there was a configurable start-up script to check how many snapshots there are and auto delete the oldest one... say keep 3or4.

Last edited by hunterthomson (2010-06-30 11:02:08)

extofme · 2010-06-30 22:46:57

hunterthomson wrote:

So, when you put out the new mkitcpio hook I'll give btrfs another go and I am sure I'll have better luck with no compression.

well, the gains i expected to get from .34 are moot. i was trying to avoid mounting the disk to list snapshots, but i forgot you have to have it mounted to do a "btrfs subvolume list" anyway (i was thinking you could do it against the device... not yet)

the only other thing i was going to do in .34 was maybe use "btrfs set-default", so you don't really need to wait around for me. the btrfs module in .34 is better; my fiancé's new eee s101 w/SSD is easily outperforming my thinkpad t43.

hunterthomson wrote:

I'd like to put my vote in for Option #1
Just make a copy of the current kernel+initramfs and append a new entry in menu.lst
I have no qualm with editing memu.lst files. If any thing goes wrong it is easy enough to just hit "e" and edit the boot line.
The problem I see it that ether of the 3 solutions mentioned seem costly. I mean there is no reason to make a copy of the kernel+initramfs "every" snapshot. How would it go about checking to see if a kernel copy was needed, just uname -r ? It would be safer to do a sha1sum but time consuming.

yeah, im not sure what im going to do about that problem yet; i think i will end up implementing 3 ways, and making it configurable. personally, i'd rather only backup the kernel+image, only when needed, and put it in a dedicated "kernel" subvolume.

hunterthomson wrote:

You know what would be cool would be to have a new grub menu.lst entry made for every snapshot. If a new kernel+initramfs is needed then call that and if not then just link to the currnet one with need boot flags to roll back to the snapshot. It would also be cool if there was a configurable start-up script to check how many snapshots there are and auto delete the oldest one... say keep 3or4.

yeah, most of these kind of operations should be done by the tool i (slowly) working on, not the hook itself. ill try to push out an update to this soon; been swamped with some projects, and i've been spending most of my free time working on a new AUR (aur-pyjs)

C Anthony

hunterthomson · 2010-07-01 11:07:29

Right on,

I am sure btrfs is fast enough because of what the benchmarks show. What I am looking for is it's ability to multi-task. Before it seemed that it could only run one thread at a time. That would be find for normal usage but I run 4-6 VM's at a time so I need super high I/O bandwidth. I would not be surprised if the behavior I experienced was a limitation from using compression.

Last edited by hunterthomson (2010-07-01 11:11:27)

tpowa · 2010-07-04 20:26:14

Joining this topic, next archboot images will support btrfs from archboot setup.
I'll start experimenting with your hooks now, are you fine with putting your stuff into the official repository?

extofme · 2010-07-05 00:50:54

tpowa wrote:

Joining this topic, next archboot images will support btrfs from archboot setup.
I'll start experimenting with your hooks now, are you fine with putting your stuff into the official repository?

yes definitely, add it. apologies; Thomas Bächler contacted me in regards to submitting this hook for inclusion, but i hadn't got to it yet.

some considerations:

) perhaps you could read the last couple posts; we have been discussing the best course of action to handle kernel/boot partition rollbacks (as it is not on the btrfs FS)
) everything will be much easier if the user's system is installed into a subvol called /__active from the start. the default subvol should be reserved for "managing system state" and not "the system itself/files"
) right now, btrfs-progs does not include the new "btrfs" utility (only in -git). the hook requires this for any rollback functionality, although this could be changed by using wrapper functions for certain operations
) the btrfs_mount_handler_DEP() function should probably be updated to check for a /__active subvol, else it /sbin/init won't be found on those systems

lastly, there is no utility to snapshot the system properly ATM. i am working on a proper tool... slowly... but a 10 liner is all that's really needed:

1) mount the default subvol
2) snapshot <mnt>/__active to <mnt>/__snapshot/XX-YY-ZZ (no spaces in filename)

that will make the snapshots available at boot time.

i've been pretty crunched on time lately for about 15 different reasons, but lmk of any changes you need to the scripts and i will do it.

C Anthony

ps. i have playing with the new set-default and list btrfs commands in 2.6.34, but they don't quite do what i expected. i _thought_ that setting a new default meant a new default for _mount_ only, but it doesn't seem to work that way. after setting a new default, mounting with the "subvol=." option mounts the _new_ default, not the "real" btrfs root. this seems to effectively make the original root impossible to ever mount again, as i don't know how to get it's internal ID (the list command only shows created subvols, not the original "."). it also seems to swap any subvols mounted with "." IN REAL TIME... this caused my processes on the subvol to hang, and ended in some kernel oopses. just a heads up, as i was having problems mounting subvols by ID as well, but this might be due to some other things. check these threads for info:

http://www.mail-archive.com/linux-btrfs … 05336.html
http://www.mail-archive.com/linux-btrfs … 05278.html

this post sums it pretty good:

http://www.mail-archive.com/linux-btrfs … 05368.html

but i'm now thinking that "set-default" wasn't doing what we thought all along (i thought the "." subvol would ALWAYS be the real btrfs root).

hunterthomson · 2010-07-06 04:20:35

Okay,

I am now using btrfs on a my /root partition. I did not use the compression and now it IS using multiple processes to read/write to the file-system. When I watch top now while copying a large file to the drive it has btrfs-worker-0 btrfs-worker-1 btrfs-worker-2....... and so on. Before it would only have One btrfs-worker-0 and it would use 100% of the one core it had. Now it is no where near that load. Each of the now multiple processes uses only like 5-12% max and peaks at 20%.

Good stuff.

EDIT: Awe, you know what... I guess I could have set a mount option of thread_pool= Then btrfs would use more threads. I guess it auto detected it in ether the new Kernel or by not using the compression flag.

Found in second post on this page of the Gentoo thread.
http://forums.gentoo.org/viewtopic-t-56 … 207c53ca0a

I have to say though after reading that thread. I'm a little worried ( sure I have full backups of everything though). The main thing that seems sketch is that the fsch doesn't do anything and there is nothing that will warn me if anything dose go wrong while using the FS. So, like if the FS dose get corrupted I'd never know and even if I did there would be no way to fix it.

I have a questions though...

Would it be okay to use... extra/btrfs-progs-unstable 0.19.20100607-2
I have installed... aur/btrfs-progs-git 20100227-1 [20100614-1 installed] (25)
However, that package seems to build directly form the git tree and that makes me think that it may be less stable then the one in the extra repo that is in a known state.

Last edited by hunterthomson (2010-07-07 05:54:30)

relgueta · 2010-07-08 01:57:12

what the command btrfs subvolume snapshot / /__active does?

im have one partition for my entire install.

Last edited by relgueta (2010-07-08 01:59:43)

extofme · 2010-07-08 04:40:26

relgueta wrote:

what the command btrfs subvolume snapshot / /__active does?
im have one partition for my entire install.

i only use one partition (subvolume?) as well. everything on btrfs, one subvolume.

it makes a writable copy of your system, and that copy will be become your system. the old copy must be manually removed by mounting the btrfs root subvolume, and removing the erroneous files. do not remove __active, __rollback, or __snapshot

C Anthony

extofme · 2010-07-17 17:57:30

hunterthomson wrote:

Okay,
I am now using btrfs on a my /root partition. I did not use the compression and now it IS using multiple processes to read/write to the file-system. When I watch top now while copying a large file to the drive it has btrfs-worker-0 btrfs-worker-1 btrfs-worker-2....... and so on. Before it would only have One btrfs-worker-0 and it would use 100% of the one core it had. Now it is no where near that load. Each of the now multiple processes uses only like 5-12% max and peaks at 20%.
Good stuff.
EDIT: Awe, you know what... I guess I could have set a mount option of thread_pool= Then btrfs would use more threads. I guess it auto detected it in ether the new Kernel or by not using the compression flag.
Found in second post on this page of the Gentoo thread.
http://forums.gentoo.org/viewtopic-t-56 … 207c53ca0a
I have to say though after reading that thread. I'm a little worried ( sure I have full backups of everything though). The main thing that seems sketch is that the fsch doesn't do anything and there is nothing that will warn me if anything dose go wrong while using the FS. So, like if the FS dose get corrupted I'd never know and even if I did there would be no way to fix it.

i wouldn't hold too much of that thread against btrfs; many of the comments are misleading or outright incorrect. yeah, btrfsck doesn't do much ATM, but a large piece of it is about to hit HEAD soon. and you can still recover data... i'm not sure how exactly myself, but each time someone comes to the list with issues, Chris and others are more than willing to help them manually recover the data from it. although, i believe you can still use btrfsck to check for integrity, it just can't fix it yet.

hunterthomson wrote:

I have a questions though...
Would it be okay to use... extra/btrfs-progs-unstable 0.19.20100607-2
I have installed... aur/btrfs-progs-git 20100227-1 [20100614-1 installed] (25)
However, that package seems to build directly form the git tree and that makes me think that it may be less stable then the one in the extra repo that is in a known state.

i haven't looked, but if it includes the "btrfs" utility it will work. if not... your system likely won't boot, esp. if you enabled rollback support; you'd have to manually add rootflags=__active to the kernel boot line. i intend to make this a little more robust but i haven't got to it yet.

C Anthony

hunterthomson · 2010-07-17 20:19:12

Right on. That thread did seem a little much. I did notice at least one mistake in there. One of the guys used btrfs on his mounted file-system, and like the tools warring says, it can cause corruption if used on a mounted file-system.

litemotiv · 2010-07-18 10:18:17

extofme wrote:

i don't recommend using the compress mount option yet. zlib is too processor heavy, and could be contributing to your problems; wait for another algo to be available like LZMA(2).

afaik it's the other way around, lzma compresses better but slower than zlib. this makes lzma a good choice for precompressed data, while zlib is better for real time compression. correct me if i'm wrong though.

resi · 2010-07-18 16:47:47

Hi extofme,

I just read about syslinux which seems to have support for btrfs. That sounds like one could set up a "real" snapshot/rollback environment without copying kernels around.

Do you know anything about that?

extofme · 2010-07-18 18:41:55

litemotiv wrote:

extofme wrote:
i don't recommend using the compress mount option yet. zlib is too processor heavy, and could be contributing to your problems; wait for another algo to be available like LZMA(2).
afaik it's the other way around, lzma compresses better but slower than zlib. this makes lzma a good choice for precompressed data, while zlib is better for real time compression. correct me if i'm wrong though.

hmm, i'm really not sure to be honest. i read it somewhere, but i can't recall where; i thought it was on the btrfs list. i think the thing was that LZMA is lightweight to decompress, and you (usually) do much more reading IO than writing. at any rate, it all depends on the workload, and the system specs... if you have enough CPU you probably won't notice, but on a netbook, maybe so. i think the sweet spot is using multiple subvolumes for different parts of the system with different mount options, in the same way that many people use ReiserFS for X, Ext4 for Y, Ext2 for Z, etc. tuned for the specific workload on that part of the system (/var, etc.)

resi wrote:

Hi extofme,
I just read about syslinux which seems to have support for btrfs. That sounds like one could set up a "real" snapshot/rollback environment without copying kernels around.
Do you know anything about that?

no i have not read about that. ill check it out; want to share a link?

C Anthony

resi · 2010-07-19 07:52:50

extofme wrote:

resi wrote:
Hi extofme,
I just read about syslinux which seems to have support for btrfs. That sounds like one could set up a "real" snapshot/rollback environment without copying kernels around.
Do you know anything about that?
no i have not read about that. ill check it out; want to share a link?
C Anthony

Sure, it seems to be a syslinux derivative, extlinux. They don't mention btrfs on the extlinux page, but on the syslinux main site.

hunterthomson · 2010-07-22 01:22:58

EXTLINUX: btrfs and ext4 support. btrfs support was done by Alek Du of Intel.

Hum cool, it seems the Nokia/Intel MeeGo adoption of btrfs is paying off for the community. I love Intel.

Last edited by hunterthomson (2010-07-22 01:23:36)

extofme · 2010-10-18 15:33:54

i haven't done this yet, but this post is more of a heads up to anyone using this hook.

i have recently confirmed that syslinux/extlinux works with a btrfs root (no separate /boot partition). additionally, it works after setting a new default via "btrfs set-default". also, i discovered the "subvolid" mount option (i thought "subvol" was the only one, and i always wondered why i couldn't mount via ID). lastly, i have learned that the subvol id's 0 and 5 _always_ correspond to the top-level btrfs root, ie. the "original" root, allowing me to access the top-level root at any time irrespective the current default.

using these properties, i can now easily support kernel-level system rollbacks, without disrupting those with a separate /boot. however, it will currently only work with extlinux, and due to time constraints, and more interesting projects (read AUR3 :-), i won't be trying to support kernel rollbacks on grub/grub2 until they support btrfs booting themselves. at which point, it should Just Work.

will update soon-ish.

C Anthony

extofme · 2010-10-23 22:58:17

extofme wrote:

... additionally, it works after setting a new default via "btrfs set-default" ...

i make a mistake.

i can't do kernel rollbacks yet. what was actually happening, is the original extlinux and kernel (from the real/top-level btrfs root) was being booted, instead of the one within /__active. then, when the kernel tried to mount the root device, thats when __active came in, as it was default.

so basically, you no longer need a separate /boot partition, but you still need your kernel and bootloader to reside in the top-level btrfs subvolume; essentially what we already have, but one step closer at least :-)

will holdout on changes until this restrictions is lifted.

C Anthony

Arch Linux

#26 2010-06-15 05:34:11

Re: BTRFS mkinitcpio hook

#27 2010-06-16 01:56:17

Re: BTRFS mkinitcpio hook

#28 2010-06-18 01:36:08

Re: BTRFS mkinitcpio hook

#29 2010-06-18 06:12:09

Re: BTRFS mkinitcpio hook

#30 2010-06-20 17:29:53

Re: BTRFS mkinitcpio hook

#31 2010-06-21 03:49:49

Re: BTRFS mkinitcpio hook

#32 2010-06-21 04:50:47

Re: BTRFS mkinitcpio hook

#33 2010-06-22 06:50:14

Re: BTRFS mkinitcpio hook

#34 2010-06-30 11:00:47

Re: BTRFS mkinitcpio hook

#35 2010-06-30 22:46:57

Re: BTRFS mkinitcpio hook

#36 2010-07-01 11:07:29

Re: BTRFS mkinitcpio hook

#37 2010-07-04 20:26:14

Re: BTRFS mkinitcpio hook

#38 2010-07-05 00:50:54

Re: BTRFS mkinitcpio hook

#39 2010-07-06 04:20:35

Re: BTRFS mkinitcpio hook

#40 2010-07-08 01:57:12

Re: BTRFS mkinitcpio hook

#41 2010-07-08 04:40:26

Re: BTRFS mkinitcpio hook

#42 2010-07-17 17:57:30

Re: BTRFS mkinitcpio hook

#43 2010-07-17 20:19:12

Re: BTRFS mkinitcpio hook

#44 2010-07-18 10:18:17

Re: BTRFS mkinitcpio hook

#45 2010-07-18 16:47:47

Re: BTRFS mkinitcpio hook

#46 2010-07-18 18:41:55

Re: BTRFS mkinitcpio hook

#47 2010-07-19 07:52:50

Re: BTRFS mkinitcpio hook

#48 2010-07-22 01:22:58

Re: BTRFS mkinitcpio hook

#49 2010-10-18 15:33:54

Re: BTRFS mkinitcpio hook

#50 2010-10-23 22:58:17

Re: BTRFS mkinitcpio hook

Board footer