Re: why are / and /home the same filesystem?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2022-02-08 17:28, Gordon Messmer wrote:
On 2/8/22 04:56, Peter Boy wrote:
The quote describes a situation which has gone for more of a decade now. Since we have LVM (when got that part of the Linux kernel? kernel 2.6? 2004 or so? Don’t know exactly), no one would partition a hard disk along file system subdirectories. You create logical volumes instead, which can easily "changed without a reinstallation“ and space for any logical volume "can be expanded or restricted on the fly“. The latter even easier with „thin provisioning“.


Expanded, sure.  But restricted?  I don't think that's as clear for LVM.  IIRC, XFS can't be shrunk at all, and ext4 can only be shrunk offline.  Users should be able to create, destroy, or resize qgroups online for btrfs.

I'm unclear on what you mean is easier with thin provisioning; can you clarify that?

I may be naive here, as I use writable snapshots in LVM but not thin provisioning specifically: my impression was that users needed to be very careful not to allow the volume group to run out of space when using either of these, because filesystems generally don't deal well with the unexpected write failures that occur when LVM has no more extents to allocate.  btrfs' free space handling can be surprising to users, and statfs() might suggest there is more space available than there is, but it's not the sort of thing that can corrupt the filesystem itself.

Exactly! I tried using thin provisioning once as a way to solve the "how much in / and how much in /home" dilemna and ended up regretting it. There is no indication of how much space is really available and when it ran out, it was messy. At least btrfs gives you an accurate number even if it might be a little confusing at first why / is getting so small when you fill up /home.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux