Location of some executables
gordan.bobic at gmail.com
Wed May 11 08:39:58 EDT 2011
On 05/11/2011 12:34 PM, briaeros007 wrote:
>>> /usr can be farily sized (mine do 7.6 Go, /bin and /sbin do 22M...).
>>> you can want to have a little "/" partition for different reason :
>>> - quota things (you doesn't want your / full only because you've
>>> install a soft which copy 5 Go on /usr/share
>> You have a quota in / ??
> on /usr.
Why? Do your users have write access to /usr?
>>> - you can choose to have your / read only (system maintenance) and
>>> your /usr read write (add/modification of software)
>> So following that logic, if you then also separate out /var, you have a
>> situation where your package DB is listing packages on multiple different
>> partitions. That just strikes me as a bad idea.
> And why that ?
> Package db already manage
> /bin - /sbin
> And if you said that all theses directory are in the same partition
> (and particulary /boot and / ) ...
I can understand separating /boot (a necessity in cases such as / on MD
RAID 0/5/6 or a fs not supported by grub). But most of the rest I tend
to separate more specifically. For example, I wouldn't separate /var,
but I often put /var/lib/mysql on a separate volume/partition/disk/fs
depending on the nature of the data.
>> Apps are generally small. Data is generally big. I am all for putting data
>> onto separate volumes, but when the entire OS install + apps is smaller than
>> the amount of RAM on mid-range graphics card, I don't really see the gain of
>> splitting it up in the general case.
> Apps aren't small.
> If i install a Business Object, I must have got 5 Go of free space to
> install it. Yes 5 Go.
> If i play with BMC remedy, it's the same idea. And data are in db.
So separate that app's data store somewhere more sensible, not the
entirety of /usr.
> Everybody doesn't use their system only as a desktop.
Desktops can actually call for or at least justify _more_ partitioning
than servers, if you are using solid state storage.
>>> - boot pxe for the system (one nfs share for the core system, and
>>> other for applications which are loaded when the system initialize
>>> - etc...
>> Sounds like an administrative nightmare. What commonly available package
>> management system will cope with that?
> If you can't follow multiple nfs share, well pxe isn't for you.
> What commonly available package management system manage pxe ? none.
> I'm talking about specific need due to a boot procedure, and you talk
> about package management system. I don't see the links.
So you are complaining that a completely custom brew setup you are
running doesn't agree with the default file locations in the ZFS
package? And if you are PXE booting with NFS root how does that relate
to ZFS, exactly?
>>> /bin and /sbin are here for a reason : to provide a lightweigth
>>> environnement who can be used to manage the server, even if other
>>> partitions can't be mounted.
>>> I think It's a best practice to separate things on a server. if
>>> something bad happen, the other things aren't impacted.
>> The chances are that you're not going to get very far in fixing things
>> without the things in /usr/bin and /usr/sbin.
> So you're just saying that generations of sysadmin are just dumbass
> and protection/compartimentalization aren't useful ?
I'm saying that times and resources have changed since this was a good
idea. Compartmentalization is a good thing if used appropriately. I do
not believe splitting every directory under / to a separate volume is
appropriate for any sane use-case I can think of.
What was a good idea on SunOS 4.1.1 running off 40MB 9in SMD disks in
1990 isn't necessarily a good idea on the current generation of systems.
Blindly following pragmas deprecated by technology might imply some
dumbassness (your choice of words, not mine).
> Let's just put all the things inside a big partition, and if something
> goes wrong, well, cry.
> Example : -> the fs crash, and you lose all the data in the partition
> (and backup, as murphy law edicts, wasn't working this day)
> Did you prefer to lose just /usr, which are easily recreated, or /etc,
> /boot (can't boot withtout it ), /usr, /var and so on ?
So by that logic, are you going to put /etc on a separate partition? Can
you list me a sensible use case where losing one wouldn't usually lead
to losing the lot? You can't argue that a solution to poor backups is
partitioning /usr off to a different partition (especially on the same
backing storage, be it disk, SAN, array, or whatever).
Since /usr isn't user-writable any more than / is, I don't really why
losing one is more likely than the other. And re-creating /usr without a
backup is going to mean a reinstall/rebuild/restore whatever you do. So
IMO your example is completely bogus.
> Other example : due to unforseen evenement, you must add 4 Go to /usr or /var.
> did you want to take the risk to do an "resize2fs" on the root
> partition and an modification of physical partition, or just lvextend
> and resize2fs on a non root partition?
Why would you possibly be rationing space that tightly? Disk space is
worth £0.04/GB. So be extravagant - splash out an extra £4 in disk space
at installation time and have a 100GB /. More than you'll even sanely
use up for an app installation that you hadn't anticipated at the time
when you built the system.
> In all corporations I work, there was never a "big /". And this for
> linux, aix, solaris or hp-ux.
My experience is varied - very limited purpose hardware (server farms)
small root is relatively common (then again, in a thin majority of such
setups I've worked on Solaris is in use, and as mentioned previously,
that has /usr implicitly on /).
But I have _never_ seen a call to suddenly and unexpectedly dump an
extra 4GB of _apps_ on an existing system. That's just poor planning.
And regardless, if you are making a change of that magnitude, you'll
typically jumpstart/kickstart a new server, test the new app, the
migrate to live, not just randomly dump gigabytes of apps onto a system
that is sufficiently narrow-purposed to have a tiny root fs.
>>> the "good way" of doing this sort of choice in an , is to use a PREFIX
>>> variable with configure and let the user change it if they want.
>>> In this way, if the user want to create an user "zfs" which wil manage
>>> all binaries and lib of zfs in it's home: it's easy and possible.
>>> And nobody to say "my way of doing things is better than yours".
>> Perhaps people who believe in micro-management on this level can also roll
>> their own package with their own specific patches for their own custom LFS
> I don't have any problem with the stance "You want it ? You code it!".
> Well it's free software after all.
> What i don't understand, it's when someone say "justify it. justify
> it. It's a nonsense. Justify it. It's a nonsense".
Then don't ask for it. :)
It's not a question of justifying what you do. What you _do_ need to
justify is somebody else doing work only useful to you.
>>> I don't even understand why some must justify multiples times
>>> 1°) best practice (this is a best practice! Just take any true (plain
>>> old?) linux installer, and you will see a choice like "server : /,
>>> /usr, /home, /var, /tmp are separated).
>> I think it's time to move from 1980s to the 21st century.
> Thanks for the advice. I think that if i'm on this ml , is because i
> love eighty ;)
>> This was relevant
>> when disks were small and expensive. RHEL6 has dropped support for custom
>> partitioning in text installers - you have to run the GUI installer to do
>> custom, manual partitioning. The only way to do it without the GUI is to
>> kickstart it. Don't know about other distros, but I'd be amazed if any
>> desktop distro released in the last decade defaults to a separate /usr.
> Does linux works only on desktop ?
AFAIK, you are the first person that even mentioned desktops in any context.
> And the fact that isn't on "text install but on gui" doesn't seem
> relevant to me.
> Any server now can use a gui, and it's been some times we don't do
> console install (or in specific hardware).
So what do ancient text-only installers you mentioned have to do with
More information about the zfs-discuss