Re: [tlug] how filesystem works?

[Curt Sampson <cjs@example.com>]

On Sun, 1 Apr 2007, Stephen J. Turnbull wrote:

> If you have a devel system, 5GB in /usr is tight for many Linux
> distros.

Interesting. My /usr (which includes the entire OS install and any
additional packages I add, and always includes what I think Linux folks
would describe as a "development system") seems to sit under 4 GB even
on my desktop systems, which tend to have a lot of crud installed.
Perhaps something about the way I work just tends to have a lot less
stuff installed, though from what little Linux I've seen, it's not
really the case that they have a lot of packages installed by default
anyway.

> >      /var	0.5-2 GB	nosuid
>
> Most Linux distros put daemon data in /var, eg, web documents in
> /var/www, database data in /var/lib/db-du-jour, and so on.

Yeah, I've seen that, and I really don't like it, because of backup
reasons.

I divide my backup data into these basic categories:

    1. Essential and non-reproducable: e.g., my subversion repository.
    This stuff goes on /home, which is always backed up.

    2. Essential and reproducable, albeit with time. This usually
    includes the configuration under /etc (on the root partition), which
    I could regenerate, but which I'd rather not when trying to bring
    back a machine under time pressure. Whether or not I back this up
    depends on the cost of backup versus the cost of time it will take
    to rebuild the system. Usually I just back up the root partition,
    since it's small and thus relatively cheap to back up.

    3. Essential and easily replacable: the operating system under /usr.
    This can easily be restored from OS install media. No backups. Same
    for the web sites (which can all be restored easily from subversion)
    and suchlike, which go under /u.

    4. Non-essential and non-reproducable: log files, transient spool
    files, and temporary files under /var and /tmp. Though I might
    lose an in-transit mail message or two (I don't deliver mail to
    /var--that goes into users' home dirs), bringing a system back up
    from backups but with a fresh /var will leave you with a working
    system, even if you've lost some history of what happened before.

Note that I don't believe that non-transient data, especially stuff that
gets large, belongs under /var. Especially, I wouldn't put a web site
there. I think that people do goes back to a misunderstanding of the
4.4BSD hierarchy design (which far predates Linux, BTW).

Of course, this is changing and improving as I move on. I've now started
tarring up the mail spool and log files on some machines and placing
that tarball under /home before running the backup, so I do keep that
stuff, too, without having to back up all the other crud. Same for
webserver log files and other generated stuff that has come to reside
under /u.

Databases are a special case: normally there's no point in backing up
the files directly, since a restore isn't guaranteed to bring back a
working database. You need to dump it with the appropriate database dump
tool, which again, I do and put the result in /home before backing up
that.

Arwyn Hainsworth wrote:

> You will have problems when you run out of space no matter how you
> break up your partitions.

True, but having /var fill up becuase your logfiles, mail spool,
whatever overrun still lets your database on /u run just fine.

Oh, I forgot to mention another good reason for a small, rarely-written
root: it's less likely to be corrupted in the case of flakey hardware
or OS bugs, and it will check and be repaired faster. Both of these
characteristics are very handy if you have a system designed to run
single-user with only what's on the root parition, as BSD is. This can
save a lot of time when you're trying to rescue what you can from a
server with corrupted filesystems.

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974