-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2011 03:50 AM, Carl-Daniel Hailfinger wrote:
Am 20.03.2011 17:12 schrieb Jeff Mahoney:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/20/2011 11:25 AM, Carl-Daniel Hailfinger wrote:
Am 19.03.2011 22:21 schrieb Jeff Mahoney:
Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small.
Is there any advantage of btrfs over a bunch of ext3 filesystems on different lvm logical volumes? The lvm pv is a storage pool, and I can resize each lv (containing one ext3 each) as needed, so the problem you described does not happen for me.
The problem I described *does* happen to you. You're just so accustomed to the workaround that it doesn't seem like it's a problem anymore. That process is still using statically defined volume sizes, but you're resizing them when you need to shift space. That's not elastic. It's multiple steps that modify both file system and storage, and it's not a process I'd recommend to notice users. It's tough to not waste space when shrinking a file system unless you shrink it lower than you intend, shrink the block device, then grow it back up to the new limit. Another step. Another opportunity for user confusion.
With btrfs, outside of the initial mkfs and a single command to create a subvolume, there are no additional steps. Each logical file system allocates space directly out of the same pool. df will show the same amount of free space on all subvolumes. It's easy and allows us the flexibility to have separate logical volumes without the hassle and risk of allocating the wrong amount of space or having to jump through hoops to change it later.
Thank you for the detailed explanation. I had assumed that btrfs subvolumes would provide fs fault isolation, but it seems I was mistaken.
Yes. The underlying btrfs file system is a single file system. The subvolumes provide multiple 'views' into the file system, each with a separate root.
If you just want the elastic storage and don't need snapshots, emulating the subvolume feature on any filesystem should be as easy as mounting the filesystem to one of the desired mount moints, and then using mount --move to move upper-level directories of the filesystem to other desired mount points.
I think you're missing the point here. How is this easier? Both this solution and your original one are fairly esoteric.
My usage pattern is having a separate filesystem for / so I can reformat+reinstall the OS instead of upgrading (saves a lot of time) and elastic storage for all my data (in /home and /storage).
This is equivalent to removing the subvolume and recreating it. The advantages surrounding a reformat don't really exist in the same way they do on other file systems since it's a copy-on-write file system. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2HV9UACgkQLPWxlyuTD7IB8wCZASRr60pMKBVljbQo8kvkN6TL 77QAn0AzPboiDGJEzEdyvj/+IdDEQVMg =KBl4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org