Anton Aylward wrote:
On 06/07/2014 09:49 PM, Linda Walsh wrote:
/usr has alot more stuff in it that isn't in root: X11R6, adm db games include libexec local share (man+docs) and more...
And there's nothing to top you creating yet another file system -- easy to do if you use LVM -- and put all of /usr/share in that. It doesn't need to be mounted at boot time.
Sorry, that is not true. The boot process has things like keyboard screen fonts, etc in /usr/share. It must also be loaded at boot time. At first I was told it was not needed. When I pointed out the transgressions, I was told 'share' is part of usr, so of course it needs to be mounted too.
You could go further, have a FS 'user-other' that has all of non essential stuff from /usr and have symlinks in /usr to there. User-other' won't need to be mounted at boot time either. So the stripped down /usr can be part of the root file system.
---- Oh, so lets see, ignoring things under 1M, I see: 1.8M samba 6.7M swat 183M sbin 264M local 350M include 379M opt 465M bin1 1.3G bin 2.1G lib 3.7G lib64 17G share ---- ----- 25.7G TOTAL
df /{,usr{,/share}} Filesystem Size Used Avail Use% Mounted on /dev/root 12G 6.9G 5.2G 58% / /dev/sdc6 15G 8.7G 6.3G 58% /usr /dev/mapper/HnS-UsrShare 50G 17G 34G 33% /usr/share
I was told, and have verified it as true, that anything under /usr is fair game for being needed at boot.
If you're still bothered about symlinks from /bin to /usr/bin then you can replace them with hard links now.
---- So if I have lib,lib64,bin,sbin & share on root.... won't fit. But that's not entirely the point. Daily backups for root are about 2-3M (uncompressed). That's less than 0.03% -- 3-one-hundredths of a percent. Rather low (nearly all of /usr is that low as well), but /usr keeps growing. Upgrading /usr is much easier than creating a new root. Soon as you show me how to upgrade root w/o rebooting, let me know. I have updated /usr w/o a full reboot and certainly /usr/share is fairly trivial. I said from day one that combining root+usr made system maintenance and recovery far more difficult. Any piece of junk that requires a monolith of 27G in backing libs, configs and files is just that: junk. Just because systemd is broken into parts doesn't mean it can boot off of root -- it has huge disk space requirements for what needs to be mounted in order to boot. That's where it is monolithic and non-sub-dividable. If it was sub-dividable, I really doubt I would have had nearly the bad reaction to it that I do. But to require me to change / reformat my entire disk setup just because systemd has huge monolithic requirements, is bad design compared to init that could bring me to a console prompt with far less demands. You want to know why the boot process takes so long? It's a difference of needing 25G v. ~1 (root is big now, because I have multiple copies of some system dirs as backups, so if some piece of software "helps me" by replacing binaries in /bin or /sbin with symlinks to an unmounted partition (which is normally not mountable w/o /usr/lib64), I can more easily recover. Given the stability and 'help' given to disable root-booting, being able to easily recover is more of a necessity now, than it was when I first setup my system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org