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

[Pete Wright]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org/pipermail/talk/attachments/20120326/cce535f2/attachment.html>