NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: How big should wd0e (/var) be



    Date:        Tue, 12 Dec 2023 16:49:43 +1030
    From:        Brett Lymn <blymn%internode.on.net@localhost>
    Message-ID:  <ZXf7f7ZJ4Up2DI4A%internode.on.net@localhost>

  | Of course there are always limits but avoiding unnecessary partitioning
  | prevents the situation of watching one partition filling up and
  | forlornly looking at the huge free space on another one and wishing you
  | had made better choices.

I look at it in exactly the opposite way - it fills me with joy to
see that something has gone wild and filled a partition, and I didn't
even notice, as everything I'm doing is elsewhere, not being bothered.
[Turn on process accounting, and do a few full builds, and /var/account
will soon take over whatever space you have allowed it to occupy.]

My system has 42 lines in fstab (which of course includes the "not really
a file system" entries like kernfs ptyfs procfs - and the tmpfs filesystems
for /tmp and /var/shm and entries for the cd (bd) drive and swap).   Still
way more than 30 "normal" filesystems - many of which are not mounted when
they're not needed (one advantage of separate filesystems) and others which
are read only (like /usr - which does not include /usr/pkg which is separate).

What's more I have 2 /home filesystems, one I use, the other gets rsync'd
to and then unmounted every day or so ... the two live on different raid
sets that reside on entirely distinct drives.  /home is where all the work
I care about lives, so I want that preserved and quickly recoverable, if at
all possible -- a restore from backups (which also exist) would take all day.

I also have 2 /usr's (one in use, one to be used for the next upgrade,
then they'll switch roles) 2 /usr/pkg's (same principle, but entirely
different update schedules) and lots of root filesystems (the ones for
older versions - like -8 -9 -10 which I sometimes boot for testing include
/usr in the root so all the binaries they use match the kernel).

Filesystems as an operational object have plenty of uses, it is a mistake
to simply treat them as an accident of history brought on by drives not being
big enough, and no-one had yet invented a way of combining multiple drives into
one filesystem.  That would have been easy, the issue was more than the 2nd
and later drives tended to have removable media (well, all did, but the one 
with root needed to remain stable as long as the system stayed running),
which could be swapped depending upon which files were needed from time to
time - and hence combining those into one filesystem would not have worked.

kre



Home | Main Index | Thread Index | Old Index