Nik Clayton writes:
> Recommended disk and partition layout
>
> In order to reduce space wastage, and provide a flexible partition layout
> for future work, the following disk partition layout is recommended.
>
> First, you need three 'standard' filesystems, of roughly this size:
>
> / 50m
> /var 50m
> /usr 250m
>
> A 50m / should be sufficient for static /bin and /sbin, as well as /etc,
> other configuration files, and a local /tmp.
>
> Similarly, a 50m /var covers most log files, assuming the machine isn't
> doing anything too log intensive. Don't worry about the size of incoming
> and outgoing mail spools, or the print spooler at the moment.
>
> Finally, a 250m /usr covers all the standard stuff, and leaves room for
> expansion in the future.
>
> Now, create one more filesystem,
>
> /local/0 rest of the disk
>
> If you have any more disks, create 1 filesystem per disk, and arrange to
> mount them as /local/1, /local/2, and so on.
>
> The known space fillers can then be moved on to /local/{0,1,2,...} as
> necessary, and then symlinked back in to place. For example;
>
> mkdir -p /local/0/usr
> mkdir -p /local/0/var
> mkdir -p /local/0/home
> cd /usr
> mv src /local/0/usr
> mv obj /local/0/usr
> mv ports /local/0/usr
> mv X11R6 /local/0/usr
> ln -s /local/0/usr/* .
> cd /var
> mv mail /local/0/var
> mv spool /local/0/var
> ln -s /local/0/var/* .
>
> and so on. Adjust the disks you move stuff to, depending on how many disks
> you have, and expected usage.
>
> For example, if you only have one disk, then /local/0/usr/{src,ports,obj}
> and /local/0/home/ncvs[1] will all have to be on one disk.
>
> When you add a second disk, you will definitely want to move
> /local/0/usr/obj to /local/1/usr/obj, and /local/0/home/ncvs to
> /local/1/home/ncvs (and update their symlinks). This is because:
>
> 1. If you do a CVS checkout from /home/ncvs to /usr/src, two different
> disks will be used, speeding things up considerably.
>
> 2. If you do a "make world", the source will be read from /usr/src,
> on the first disk, and the compiled programs (and object files)
> will be written to /usr/obj, on the second disk, and again, this
> will speed things up.
>
> Problems with this approach
>
> By placing everything on one (or a few) large filesystems, you lose
> finegrained control.
>
> For example, if /var/mail and /var/spool are symlinks to /local/0/var/mail
> and /local/0/var/spool respectively, then there is the possibility that
> large incoming e-mails can use up all the disk space, preventing anything
> that requires /var/spool (such as lpd(8)) from working properly -- and vice
> versa, as large print jobs may halt reception of incoming e-mail.
>
> To an extent, you can work around this problem with quotas. For example,
> the mail system runs as group 'mail', so you can set a group quota for mail
> to prevent it filling up the disk. Some daemons also have configuration
> options to prevent them filling up the disk, such as the lpd(8) minfree
> file.
Yes, it's good.
But it's better just mount partition on it's own place, no symlinks,
such as:
/dev/sd1s1f 3942238 2151773 1475086 59% /usr
/dev/sd0s1g 985535 38016 868677 4% /usr/ports
/dev/wd2g 2030095 1437551 430137 77% /usr/ports/distfiles
/dev/sd0s1h 985535 155771 750922 17% /usr/src
and /local is not the best plase for out of the hier(7) things.
use special partition for mount points:
/dev/ad4s2h 455 39 380 9% /mnt
glip:/mnt/d 4053998 3356969 372710 90% /mnt/d
/dev/ad0 1056751 1021265 35486 97% /mnt/w
/dev/ad4s2e 16183272 1135371 13753240 8% /mnt/e
where /mnt is ro mounted and mount points in /mnt
(subdirectories) has 0777 rights:
1 drwxrwxrwx 2 root wheel 512 16 ΖΕΧ 03:23 0/
1 drwxrwxrwx 2 root wheel 512 16 ΖΕΧ 03:23 1/
.....
1 drwxrwxrwx 2 root wheel 512 16 ΖΕΧ 03:23 x/
1 drwxrwxrwx 2 root wheel 512 16 ΖΕΧ 03:23 y/
1 drwxrwxrwx 2 root wheel 512 16 ΖΕΧ 03:23 z/
so give rights to mount (via sudo) and read/write msdos fs
for all:
/dev/fd0 /mnt/0 msdos rw,nosuid,noauto 0 0
with no risk that /mnt will be changed
Another win in separating mounting points from usual hierarhy
is that it is possible to work with stalled mounts.
It is take place when mounting some unreliable carrier.
--
@BABOLO http://links.ru/
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message