Quoting Miroslav Skoric (sko...@uns.ac.rs): > Possibly ... but you need to explain that to the 3rd party software > programmers. All I have remembered to be compiled from sources > locally, went to /usr/local/.. Seems as (un)written consensus; > however nobody suggested to have /usr/local/ as a separate partition > at install.
Nobody _you_ heard, perhaps, but it's routinely done by us server admins, as there are compelling advantages, e.g., with /usr/local being distinct from /usr, you can have different sets of mount options. Here's how I designed /etc/fstab on a typical server I constructed in the middle 2000s: # <file system> <mount point> <type> <options> <dump> <pass> ## sda is (obviously) the boot drive. 73 GB SCSI. /dev/sda1 /boot ext2 defaults 0 2 /dev/sda5 none swap sw 0 0 /dev/sda6 /var ext2 noatime,nodev,nosuid 0 2 /dev/sda7 / ext3 defaults,errors=remount-ro 0 1 /dev/sda8 /recovery ext3 defaults 0 2 /dev/sda9 /usr ext2 nodev,ro 0 2 ## sdb and sdc are RAID1 mirrored, except for swap. Each is 18 GB SCSI. /dev/md0 /var/www ext3 nodev,nosuid 0 2 #sdb5,sdc5 /dev/md1 /var/lib ext3 nodev 0 2 #sdb6,sdc6 /dev/md2 /var/spool ext3 defaults 0 2 #sdb7,sdc7 /dev/sdb8 none swap sw 0 0 /dev/sdc8 none swap sw 0 0 /dev/md3 /home ext3 defaults 0 2 #sdb9,sbc9 /dev/md4 /usr/local ext3 defaults 0 2 #sdb10,sdc10 These days, I would do it quite differently, especially on account of using SSDs instead of hard drives, so, e.g., there's no need to group filesystems to minimise average seek distance/time on an SSD that inherently doesn't need to perform seek operations in the first place. However, as a detail of the above, notice that /usr is normally mounted read-only, while /usr/local is not. This different requires that they be distinct filesystems. (/usr is also ext2 in this example, as there's no advantage to the overhead of journaling on a filesystem left normally read-only.) In case people are wondering, details of how to keep /usr mounted read-only and still let apt work correctly without manual intervention can be found here: http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00212.html Having /usr normally unmounted is an example of routine caution against likely failure modes: That filesystem is where almost all system programs and libs live, and on a typical Linux system is (at least by default and initially) where most of its complexity and disk usage is. It is a tree you as local system administrator wish to protect against mishap. The most likely source of such mishap is: you, the local system administrator. I have /usr normally unmounted in order to have in place a first-level default protection against the worst threat to its orderly management and contents, i.e., against myself. If I am careless with the root-user account and launch a recursive chown of something that would cascade down /usr, for example, it will (by design) fail. Pretty much the only time /usr needs to be mounted read-write is during package operations. For that exact reason, I have a pair of scripts invoked via dpkg hooks (see debian-devel link, above) that remount /usr read-write just before packages get installed or removed, and then remount it read-only again immediately when the package operations are done. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
