On 03/23/2016 08:40 PM, Chris Murphy wrote:
On Wed, Mar 23, 2016 at 5:58 PM, Anton Aylward <opensuse@antonaylward.com> wrote:
[snip]
How do you create an LV when you have no free extents in the VG to create the LV?
I've already dealt with question a number of times. So long as there is a SCSI slot or a SATA socket free to plug another spindle in it can never happen. But that's an extreme case in these days of terabyte drives. if you've created a system that said the RootFS is 10G (including /boot) and the rest of your 1T or 2T (or is it 3T these days?) drive is the /home XFS then perhaps you weren't thinking about provisioning when you did the install. I would expect that people as experienced as Thee and Mee would think about how much space to allocate now, even if it is to matters like SWAP if you're doing the "One File System To Rule All Drives" approach with BtrFS. The OP and many here do seem to make use of partitions. I get the impression that people like Carlos and Felix do a LOT of partitions :-) The machine I'm typing at has a 1T drive with separate /boot and SWAP and pvscan tells me PV /dev/sda3 VG vgmain lvm2 [924.06 GiB / 520.06 GiB free] I have a LOTS of 5G LVs (which back up onto DVDs) and a number of 32G LVs (which back up onto USB sticks), the latter containing extensive video, extensive music, and very extensive photographs by year. If I were to add a another spindle to the volume groups that scatter-gather capability of LVM (like that of BtrFS in "Rule them all mode" means I can have a FS that overlaps the drives, something not possible with conventional partitioning. In fact I can grow a number of file systems so that they overlap more than one drive.
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?
Not quite. With LVM if there is free space anywhere you can create a LV. Other partitioning methods need continuous (or is it contiguous) space in order to create a file system. I think I made that clear above. OK make it more explicit: I have a drive with file systems that fully fill it. Small case. I have a 30G drive with three 10G file systems. I cannot grow them on that drive. Of that 30G is a LVM VG I can add another drive, include it in the VG, and now I can grow the LVs and hence the file systems - ALL OF THEM. And yes I acknowledge you can do similar with BtrFS. But you can't do that with any file system that need a continuous (or is it contiguous) span of a partition, such as just about every other file system we've touched on. Do we need to get to ZFS? I hope not :-) Yes there are tools that will merrily shuffle the partitions back and forth, claiming, and I hope succeeding, in preserving the file system on the partitions as they get moved. But that takes time. I've done it. I find it scary! With LVM I get immediate results and I don't have to worth about any problems resulting from sliding partitions back and forth. Of course that may not concern you. As they say, "YMMV".
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.
Not all file systems can shrink and expand. That's the situation, a you pointed out, that the OP is in. XFS can't shrink.
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.
Or maybe not. You're assuming the need to add a new drive rather than just a LV. Or extend the LV and grow the FS (two commands). (Actually its one: fsadm resize <device>) But then in the BtrFS case it is occupying the whole drive so there would be no need to do anything at all. Right. Lets not even think of ZFS. I very particularly don't want to deal with the case of ZFS.
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.
Yes, late model kernels support growing ext4 while online :-) You do have to grow the 'partition' first, which is easily done online if it is a LV, but another matter if its a regular style partition and that needs reshuffling other partitions using the scary-hairy mode of gparted.
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,
Which is what the OP was facing.
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.
I'm not convinced that 10G is the default root unless the installer is faces with a small disk (say 30G to 50G), but yes, any default that is so weak as to make root just sufficient (plus some slop) and the rest to /home is making a mess of provisioning. With terabyte drive the installer should strongly suggest space for things like /var, /opt and /tmp, or at the very least, if the RootFS is to be BtrFS and those to be subvolumes, then recalculate the size of the RootFS to accommodate what those would been as suggested sizes if they were to have been separate. A 10G that included all those simply is not adequate. heck, a 10G without them is not adequate! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org