Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tlug] how filesystem works?
- Date: Wed, 4 Apr 2007 10:29:08 +0900 (JST)
- From: Curt Sampson <email@example.com>
- Subject: Re: [tlug] how filesystem works?
- References: <20070329090009.GK3981@example.com> <firstname.lastname@example.org> <20070329114843.GL3981@example.com> <460BAF7A.email@example.com> <20070330070435.GM3981@example.com> <firstname.lastname@example.org> <email@example.com> <Pine.NEB.firstname.lastname@example.org> <460FD438.email@example.com> <461069F6.firstname.lastname@example.org> <email@example.com> <4610C680.firstname.lastname@example.org>
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 <email@example.com> +81 90 7737 2974
Home | Main Index | Thread Index
- Prev by Date: [tlug] (no subject)
- Next by Date: Re: [tlug] Feisty Upgrade, USB issues and other oddities
- Previous by thread: Re: [tlug] how filesystem works?
- Next by thread: Re: [tlug] how filesystem works?
Home Page Mailing List Linux and Japan TLUG Members Links