|
|
| (19 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | About this Adrien,
| + | Does btrfs-zero-log work only on a single partition or can it handle BTRFS filesystems spanned across several devices? |
| | | | |
| − | <pre>
| + | == LVM functionality is only partially replaced by BTRFS == |
| − | # mkdir /live-root
| + | |
| − | # mount -o subvolid=0 /dev/sda4 /live-root
| + | |
| − | # rsync -aHA --exclude="/live-root" / /live-root
| + | |
| − | </pre>
| + | |
| | | | |
| − | -- Indeed this is much better than my original idea I would also add -X to preserve all extended attributes.
| + | One thing about LVM Volumes in contrast to btrfs sub volumes is quota's. |
| | + | Every LVM VOlume has a hard quota and if it runs out of space other volumes are not running out of disk space. |
| | + | This is one functionality that btrfs has not (yet) implemeted. |
| | | | |
| − | If you had install your Funtoo box inside a subvolume....
| + | For this reasson I stil use LVM, but with btrfs filesystems in the volumes and not with ext4 (anymore). |
| | | | |
| − | For exemple :
| + | == SHow free blocks in btrfs == |
| | | | |
| − | <pre>
| + | The other day I had a btrfs FS that was running out of disk space. |
| − | Subvolid=0
| + | But df -h showed that there was still 20% free (subvolumes a presumably not calculated since they are seperately mounted?). |
| − | ----> @root id=255 or any number
| + | And du -s works the other way around (this also calculated subvolumes and sums, so it counts the unaltered blocks in snapshot sunbvolumes extra). |
| − | </pre>
| + | Is there a way to find out how much free blocks there are available in a btrfs filesystem? |
| − | | + | |
| − | --- Please don't use @ in front of snapshots names, this is an horrible bad practice to ban. A VFS structure should remain transparent at anytime (this is the reason of why subvolumes are threaten like directories without fancy names by the kernel). What is true on a machine can be false on another, good luck for applications compatibility especially with complex structures implying nested directories/subvolumes.
| + | |
| − | | + | |
| − | You would be able to use this instead :
| + | |
| − | | + | |
| − | <pre>
| + | |
| − | | + | |
| − | # mkdir /live-root
| + | |
| − | # mount -o subvolid=0 /dev/sda4 /live-root
| + | |
| − | # cd /live-root
| + | |
| − | # btrfs subvolume snapshot @root @live-root
| + | |
| − | </pre>
| + | |
| − | | + | |
| − | I think that you should add something about installing a Funtoo inside a subvolume instead of installing it directly inside the subvolid=0
| + | |
| − | | + | |
| − | --- Why not but I don't see clearly what would a major differences of installing a distribution in another subvolume rather than 0 would be.... I should dig to measure the consequences :-)
| + | |
| − | | + | |
| − | | + | |
| − | --- Installing a distribution in a subvolume give a great advantage. First, Now on my system, each time I emerge something, update something or depclean, I get automatics snapshot of them so I can do a very fast recovery after reboot (Or I can boot any prior version of my funtoo very easily. Also, The way I use subvolume give me the ability to copy/rsync everything *without* the mounted stuff if the from of my copy is the subvolume, "/var/disksetup/@root" on my system instead of / | + | |
| − | | + | |
| − | The other advantage is that all my subvolumes and snapshots are outside of my normal Funtoo VFS so safe from any human error because not mounted by default. I use the @ in the front of my subvolume (and not my mounting point pointing to them) to simply identify them as subvolume.. No incompatibility involved, the only tool who deal with them is the btrfs module and the btrfs-progs tools and the subvolume containing them is not mounted by default.
| + | |
| − | | + | |
| − | In case if I break totaly my /, it's a lot faster to delete the @root subvolume and make a snapshot of the latest good snapshot as @root than... copying the whole snapshot to / so I get, instant recovery.
| + | |
| − | | + | |
| − | [[User:destroyfx|destroyfx]]
| + | |
| − | | + | |
| − | Also, you can even use a @home as a subvolume and with that, you can have 2 separate strategy to backup your stuff.
| + | |
| − | | + | |
| − | Snapshot your @home every hour and @root every 12 hours.
| + | |
| − | | + | |
| − | | + | |
| − | There's a lot avantanges with subvolume.
| + | |
| − | | + | |
| − | [[User:D2 racing|D2 racing]]
| + | |
| − | | + | |
| − | My / (@root) is snapshoted at system modification with emerge and my /home (@home) is snapshoted at shutdown. This is a lot less hassle to manage for my automated recovery scripts... But maybe an hourly home backup is possible with some improvements.
| + | |
| − | | + | |
| − | [[User:destroyfx|destroyfx]]
| + | |
| − | | + | |
| − | | + | |
| − | Again: using fancy names is not a good pratice in the general case. See my arguments before, you can scan a BTRFS volume to see what subvolumes are in it..... I can have subvolumes at several place in the VFS and some other others machines may not follow the same layout or not use subviolumes at all. Fancy names = pratice to *ban*.
| + | |
| − | | + | |
| − | | + | |
| − | [[User:404_Error|404_Error]]
| + | |
| − | | + | |
| − | Beside the fancy naming for snapshot, I don't understand why you insist to install your box directly inside the subvolid=0.
| + | |
| − | | + | |
| − | For the record, install an Ubuntu 11.04 inside Virtualbox and install only one btrfs partition just to play with it.
| + | |
| − | | + | |
| − | You will see that the Ubuntu installation will use the @ subvolume for the root partition and the @home is an another subvolume below the standard subvolid=0.
| + | |
| − | | + | |
| − | I'm gonna ask the question on the BTRFS mailing-list and I hope that Chris will answer it :P
| + | |
| − | | + | |
| − | For the rest, we need to wait and see :P
| + | |
| − | | + | |
| − | [[User:D2 racing|D2 racing]]
| + | |
Does btrfs-zero-log work only on a single partition or can it handle BTRFS filesystems spanned across several devices?
One thing about LVM Volumes in contrast to btrfs sub volumes is quota's.
Every LVM VOlume has a hard quota and if it runs out of space other volumes are not running out of disk space.
This is one functionality that btrfs has not (yet) implemeted.
For this reasson I stil use LVM, but with btrfs filesystems in the volumes and not with ext4 (anymore).
The other day I had a btrfs FS that was running out of disk space.
But df -h showed that there was still 20% free (subvolumes a presumably not calculated since they are seperately mounted?).
And du -s works the other way around (this also calculated subvolumes and sums, so it counts the unaltered blocks in snapshot sunbvolumes extra).
Is there a way to find out how much free blocks there are available in a btrfs filesystem?
