Location of some executables

briaeros007 briaeros007 at gmail.com
Wed May 11 09:40:10 EDT 2011

2011/5/11 Gordan Bobic <gordan.bobic at gmail.com>:
> 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
>> /boot
>> /etc
>> /bin - /sbin
>> /lib
>> /usr
>> /usr/local
>> /opt
>> /var
>> 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.
You can do what you want.
All I wanted to say is that "your way of doing things are not the only
one, and isn't more, or less, "good" than others.

So all arguments where someone must justify multiples times before you
their decisions isn't, imho, just the right things to ask.

If you think this isn't worth your time/effort or other tasks are more
useful to do, just say it in a clear way.

>>> 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.
Data store are ALREADY in a db, so not with the apps (and on a separate server).

>> 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.
A desktop with ... 99% of the time only one session, no critical apps
and onlye one  "nine" of availability (ie 90%) needs more care than
critical servers.
I don't agree, but it's only me after all ;)

>>>> - boot pxe for the system (one nfs share for the core system, and
>>>> other for applications which are loaded when the system initialize
>>>> itself).
>>>> - 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?

I don't complain.
I never complained on this ml.
You wanted use cases where /usr are not on the same partition. I give you one.

>>>> /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).

I'd love to be a dumbass who apply choice wich simplify administration ;)
And to have separate partition instead of a big / simplify the
administration when you must act or diag  on system fs.
(and you can do parallel fsck ^^)

>> 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).
I love you.
No sincerely.
I give you just a simple example. And yet you use theses example as if
it was all a new paradigm about system admin.
Well, it was just what i say first : an example. perhaps not the best
one, but only an example.

Poor backup IS a trouble that i've found in nearly ALL entities I've
come across. And big entities!
Multiple problem impacting one critical server at the same time exists.

Hopefully, theses problemes represents less than 1% of normal platform
but they do exits
And when it strikes, you doesn't want to add more troubles to the incident.

> 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.

/usr , and /etc are "apps writable" in some configuration.
and /usr is more "every day" or application management, and "/" is
more system management.
The two things are not always on the same team.

>> 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.
Excuse me ?
When you ask a server you are always working
- without recommandation or technical procedure
- can command any hardware which exists
- add any options to it
or you are restrained in your choice of hardware, software AND configuration ?
(and SAS disk aren't 0.04/GB but budget isn't really the point here.
When i've got a blade with 70 Go disk to mount an oracle server with
50 GB of datafile ... I wouldn't create a 100 GB /usr. And experience
learns me that you must always let some unallocated free space with
lvm for subsequent demands)

Actually, the technical procedure i've got to use rhel is
/ : 1G
/home : 1G
/opt : 1G
/tmp : 1G
/var : 2G
/usr : 2G

I don't decide if I want to make more or less. My enterprise says "you
create the system with theses settings, and only after you adapt".

>> 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.

I have already seen this one.

You've got a server which was correctly adapted for an apps.
you install the apps, you do all the configuration with specific
procedure and so on.
Well pretty though stuff.
All works ok.
You manage the server normally, and follow what the client ask. And
they asked to add this apps, this account and so on the webserver.

And one day you must add a security/... update of the apps (or another
apps, or ..).
the update ask you 5 Go of free space
But you don't have 5 Go. What do you do ?
1°) you recreate a new server and lost one weeks of works ?
2°) you say to the client :  "i can't do this, technically i could but
i doesn't want since it's not up my standards"
3°) you say to the client  "well, it's not optimal, but i could do
this and that to make it work. Are you ok with that?"

If you want to say that "poor planning". Yes certainly.
It's not perfect.
Yes it's not perfect.

But it's a real life example.

>>>> 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
>>> build?
>> 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.

Yes, to say that linux isn't use only on desktop.
Desktop and server have not the same need, and some of the
"explanations why it's good to have on big /" didn't go well with
servers needs.

>> 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
> anything, then?
I'm afraid my explanation wasn't clear.
If I used  "true (plain old?) installer" was to show two things
1°) that it's a policy which was well established and wasn't just some
folks fancy.
2°) to not take into account desktop centric installer.

> Gordan

More information about the zfs-discuss mailing list