Mailing List Archive

Support open source code!


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

Re: tlug: LILO Vs. 1024??



On Wed, Oct 07, 1998 at 01:02:36PM +0900, Jonathan Byrne - 3Web wrote:

> On Wed, 7 Oct 1998, Rex Walters wrote:
>
> >I *strongly* recommend by the way that you partition this thing into
> >multiple partitions. I don't believe in one big ext2 filesystem for
> >all of your Linux data.
>
> What benefits does this get me, and/or risks if I don't?

A filesystem is just a very complex data structure. The leaf nodes in
the data structure contain your data. Losing or corrupting data in a
leaf node is bad, but losing or corrupting *metadata* (info about the
structure itself) can be catastrophic.

The main reason to use multiple filesystems (IMHO) is to
compartmentalize this risk. Corrupting (or simply filling) filesystem A
won't affect filesystem B in any way.

At the very least, you almost certainly want to keep *your* data in
separate filesystems from OS data.  You'll appreciate this the first
time you try to upgrade your operating system (or if you want to try
multibooting different OS partitions).  It's nice to be able to have
separate / & /usr partitions for TL/RH/Debian or say for a 2.1 kernel
and 2.0 kernel and still be able to mount the same home directory under
all of them. And having the install scripts for your upgrade newfs the
filesystem containing your home directory is never fun.

You also gain administrative flexibility.  You can choose different
optimizations for each filesystem (space/performance, number of inodes,
max-mount-counts before fsck, raid choices, etc.).  You can optimize
based on data flow and access patterns.  Read-only filesystems can be
configured differently from heavy-write filesystems, mostly-sequential
from mostly-random, mostly-logs from mostly databases, and so on.

You're experiences recently should point out the benefits of a small
root partition wrt BIOS limitations.

The ability to do "full dump" image backups and restores is also a big
plus. This is especially true if you're able to mount a filesystem
read-only -- you *know* you can safely restore a dd image if it was
created while the filesystem was read-only.

There are, I'm sure, even more reasons that I've missed, but
fundamentally the reason to have multiple filesystems is that not all of
your data is the same.

I actually stumbled across another benefit of multiple filesystems
at home the other day. I've actually got several large disks on my
system at home, each chunked up into multiple partitions. I'd created
filesystems on all of these partitions all on the same day. Since
I don't leave my home machine running all the time, all of these
filesystems are mounted and unmounted pretty frequently (at least once
or twice a day).

Linux as a sanity check forces a fsck on a filesystem at boot time even
if it was cleanly unmounted if a certain amount of time has elapsed or
too many unmount/mount cycles have occured (20 by default). Every week
or two I'd go to boot my machine and have to wait an infuriatingly long
time for everything to come up as multiple 2+ GB partitions were fsck'd
(even with fstab saying to do 'em in parallel it took a while).

The solution was to run "tune2fs -c" on each filesystem and specify a
different max-count before check for each. This way I should never have
to fsck more than one or two filesystems during a single boot. I also
took the opportunity to bump the frequency of forced fscks way down.
Much nicer.

Convinced?

Regards,
-- 
Rex
---------------------------------------------------------------
Next Meeting: 10 October, 12:30 Tokyo Station Yaesu central gate
Featuring the IMASY Eng. Team on "IPv6 - The Next Generation IP"
Next Nomikai: 20 November, 19:30  Tengu TokyoEkiMae 03-3275-3691
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links