[nycbug-talk] Cool read about history of /bin /usr/bin/

[Edward Capriolo]

That is interesting.
I typically do not mount volumes (especially nfs) off / because
programs like slocate need to be configured to skip them. (I know FTW
slocate but I use it) Since slocate dodges /mnt and a couple other
places I use those.

I did not know the /mnt temporary deal. It seems that like /usr/bin
and /bin I have gotten a standard from the wrong way I always see
things.

I see what you are saying about /var/log and /var/lib/db. Your points
are well taken with two caveats. Linear log writes in /var/log
appending usually does not competes with a database. If there is
contention you are likely logging to much anyway.

I do agree that you always want to isolate the IO across devices
considering cost and power, however in reference to the /var/lib
conversation packages need a sensible default to persist stuff on a
single disk system. In that regard I think /var/lib//${something} is
an acceptable choice so is /usr/local/${something}.

On Mon, Mar 26, 2012 at 10:34 PM, Pete Wright <pete at nomadlogic.org> wrote:
> On 3/26/12 12:25 PM, Edward Capriolo wrote:
>
> /var/lib is ok I think. Each daemon that needs to store data defaults
> to /var/lib/${daemon}. Also your logs will go to /var/log, so in
> practice /var is all disk besides /boot and / (and home if you are
> supporting it). In the end anything that really cares about disk
> performance will likely use /mnt/something.
>
> yea i'm not too sure i really buy that argument though...
>
> back in the day it wouldn't be uncommon to find systems with shared,
> read-only, mounted / /boot /etc volumes.  /var/log may be going to a special
> device with special mount options.  dropping DB files for example under
> /var/lib/my_db/ on the same volume/partition as var log could quickly lead
> to disk i/o contention issues in some use cases.
>
> also /mnt is meant to only be used for temporary mounts, not long term
> filesystems(1) - so establishing that is a best practice should be frowned
> upon as well IMHO.  i've worked in environments where we have predictable
> mount points for application specific volumes that are mounted off of root -
> then sym-linked back into the expected data directory for a given
> application.  for example /u00 would be for primary pg_data volumes, /u01
> would be for pg_xlog's and /u02 for pg_tablespaces on a PostgreSQL system.
> Each of the mountpoints would then symlink back to their expected location
> under $PGDATA.  (while it may be technically best to use /srv for these
> datatypes - i've found that this method has served us well on our DB
> clusters).
>
>
> (1)
> http://www.pathname.com/fhs/pub/fhs-2.3.html#MNTMOUNTPOINTFORATEMPORARILYMOUNT
>
>
> -pete
>
> --
> Pete Wright
> pete at nomadlogic.org
> www.nomadlogic.org
>
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk
>