On Wed, Mar 23, 2016 at 5:58 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/23/2016 07:24 PM, Chris Murphy wrote:
LVM is not relevant at all in this case because even with LVM, XFS being used for /home still means it can't be resized, and therefore a tear down would still be required.
I disagree. This is why.
Suppose I have /home as XFS in a 20G partition (aka LV) and 'df' tells me I'm only using 10G of that. So I create a new LV, Say I make it 15G.
Now I have a few options. If I want to keep using XFS I can mkfs.xfs that LV, rsync the contents of /home across, rename the "HOME" LV to "oldHOME" and rename the new LV to "HOME".
How do you create an LV when you have no free extents in the VG to create the LV? If you have free extents in the VG to make an LV, then the analogous layout is unpartitioned free space of the same size, in which case you can partition it, use partprobe to update the kernel, and then 'btrfs add' to add the partition to the existing btrfs volume. It's not exactly a fair comparison for you to say LVM has an advantage when there's free space to make an LV, and yet you don't grant the same free space existing in the non-LVM case, is it?
Of course in my infinite wisdom and foresight (gained by getting it wrong in the past) I choose to have the entries in /etc/fstab mount by name rather than mount by UUID :-)
Another option is to mkfs.reiserfs since ReiserFS can, in the future, be both shrunk and grown, while mounted, without shutting the system down. I'm rather enamoured of that option :-)
I have tried NilFS2, which can be shrunk or grown. If you are using a SSD you might look at this. It worked OK when I tied it, and it works for mounted (aka live) file systems, but I don't see a compelling reason to use it on spinning rust other than its continuous snapshotting. That *might* be relevant for /home/ for users who make a lot of mistakes and need to retrieve previous iterations of files.
I don't understand the relevance of this to either what I said, or the thread. If you've created a custom layout that reserves free space for future use, you get the credit for doing that. It has nothing to do with LVM. And I'm even less understanding the relevance of other file systems in the discussion.
Then, of course, there's ext4FS. This can be resized with resize2fs, and it can both grow and shrink the size of the file system.
And that would have been useful, despite being an offline only shrink. The partition can then be changed to fit, a new partition in its place, and 'btrfs add' that extra partition, done. LVM really doesn't make things easier, faster, or better in the context of this thread. If anything it's more complex because now there's a whole set of emacs like things you have to do to get the equivalent of 'btrfs add /dev/sdX': pvcreate vgextend lvcreate mkfs edit fstab mount That's six commands to one. Maybe I'm missing a command in there, that'd actually be funny and help prove my point.
The downside is that this has to be done off-line, that is with the FS unmounted. (So far as I can tell. If I'm wrong, please correct me and give details.)
Yes, ext4 is offline shrink only at the present time.
My conclusion with all this is that XFS is not an auspicious chose if you have the least uncertainty about provisioning.
I think XFS is fine. The problem I have is that given it doesn't support shrink, the default layout should defer more space to root than it does. 10GiB is what I'm hearing and that's pretty small to then also hand over all remaining space to swap and an unshrinkable /home. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org