> I'm not 100% convinced here. You could well have a point about /usr/lib
and
> /usr/bin /usr/sbin, but beyond that it depends abit on how you use your
system.
> For me /usr/local/ and /usr/src are huge and growing all the time. Also
the
> random mix of make and make clean on a variety of different source trees,
can't
> be good fragmentation wise!
I agree about it depending on how you use your system, and I tried to say as
much at end. No argument with dividing things up more if you need to, I was
trying to explain partitioning of 'system' areas, with a view to robustness
and with extra disks performance. (BTW Interleaved swap spaces are also a
good idea).
Your system will run without /usr/local & /usr/src, so they're very like
user data in that respect. You could for instance symlink them into some
other partition which you backup regularly, rather than set aside dedicated
partitions (perhaps 2.4 remounts will provide a neater way to do this).
Fragmentation shouldn't occur significantly except with NFS partitions which
use synchronous writes, and end up using lots of small extends on serially
written files. NFS v3 which is now in 2.2.19 is supposed to help overcome
this, by avoiding synchronous writes. There was quite a market in NFS
accelerators a few years back, which used NVRAM to fake the disk writes, for
NFS, then wrote later from cache in large block sizes. If you do have lots
of fragments it may be because your fs contains lots of small files.
If you meant scattering of files, due to poor block allocation (like
fragementation you get in FAT and VMS style filesystems), the main thing
with ext2 is to have a reasonable amount of free space, if you expect lots
of writing. It maximises the chances of finding blocks in the same cylinder
(group), and avoids lots of seeking.
Interestingly log structured file systems say this doesn't matter in these
days of lots of RAM, and they write sequentially, interleaving files if they
are written in parallel, and rely on the (large) disk block cache, held in
RAM to give good read performance.
Hope that clears up what I was getting at. Really there's no one solution,
and beware the perils of over optimisation for your current usage, as time
will make it a royal pain...
Rob
--------------------------------------------------------------------
http://www.lug.org.uk http://www.linuxportal.co.uk
http://www.linuxjob.co.uk http://www.linuxshop.co.uk
--------------------------------------------------------------------
This archive was generated by hypermail 2.1.3 : Thu 22 Nov 2001 - 13:10:46 GMT