[gentoo-amd64] Re: Re: Re: Wow! KDE 3.5.1 & Xorg 7.0 w/ Composite

[Duncan]

David Guerizec posted <200602060112.16917.david@××××××××.net>, excerpted
below,  on Mon, 06 Feb 2006 01:12:16 +0100:

> On Friday 03 February 2006 17:28, Duncan wrote:
> <large cut of very interesting things ;)>
>> PKGDIR="/pkg"
>> PORTAGE_TMPDIR="/tmp"
>> PORTDIR="/p"
>> PORTDIR_OVERLAY="/l/p"
>>
>> Here you can see some of my path customization.
>
> Are these different partitions ? And if so, does that relate in any way to
> filesystem fragmentation ?
>
> (waiting explanation on how to fight against fragmentation here ;))

Yes, different "partitions".  Or, they /were/ different partitions on my
old single hard drive.  I'm now running md, the multi-disk kernel-RAID
driver, with four Seagate 300 gig drives, partitioned and multi-RAIDed
into RAID-1 (/boot), RAID-6 (most of the system) and RAID-0 (the stuff
like /tmp and /p, $PORTDIR, as these are either temporary anyway, or
easily replaced off the net, so the speed and additional capacity of
RAID-0 is good, and the redundancy of real RAID unneeded).

Fragmentation doesn't tend to be as much of an issue on Linux, with "real"
filesystems, as on MSWormOS, particularly FAT/FAT32.  I'm running all
reiserfs here, FWIW.  It doesn't have a compaction tool (defrag, on
MSWormOS), but I've not noticed any issues as a result.

That said, yes, the partitioning does help, as does the better separation
of executables vs data on Linux, as compared to MSWormOS.  There are other
reasons to partition that I consider more important, but it does help
fragmentation, as well.

First, while it's possible to separate /, /usr, and /var, and I've
separated them in the past, I've come to the conclusion that it's more
trouble than benefit, altho I do put some subdirs on their own partitions.
Keeping those three together means all the locations portage will normally
place merged package components are on the same partition, along with
portage's database of what's merged.  I've had them get out of sync
before (long story, suffice it to say it can happen, particularly if they
are on separate partitions), and take it from me, it's /much/ simpler if
the database is always synced with what's on your system.

I /do/ however keep two copies (and I should have made three) of that /
partition (with /var and /usr), a working copy and a backup, such that I
ever fat-finger something, or if a package upgrade kills my ability to
boot for some reason (possible, running ~arch), I can simply boot the
backup copy.  (That's actually how the de-syncing happened above, after
something happened, I ended up with a  /var from the working copy and a /
and /usr from the backup, so portage thought everything was up to date,
when it was all as old as the backup snapshot -- a difference large enough
to complicate things.)  If it's three, working, fallback, and second
fallback, you'll have a working fallback at all times, even if something
happens in the middle of your update of the first fallback, since you'll
have the second, and wouldn't attempt an update to it until you've
verified the first fallback works after you updated it.

As I mentioned, some of the subdirs of the above are separate partitions. 
/var/log is on its own partition so a runaway logging incident can't ever
use up all available space anywhere but the log partition.  This is common
Unix practice.  /tmp is its own partition because it just makes sense to
keep temporary files isolated from the rest of the system.  (Here,
/var/tmp is a symlink to /tmp, so it's the same partition.  They do have
slightly different uses, so that's not for everyone, but it was standard
on Mandrake, which I switched to Gentoo from, and it suits my needs. 
Servers and true multi-human-user systems where not all human users are
trusted will be most likely to wish to keep these separate.)  /usr/local
is its own partition, so I can keep the scripts and stuff I have there
across main system reinstalls, if necessary.

/home is of course one of the first partitions often split off, again,
allowing system reinstall without killing the stuff in /home.

Of course, note that these splits also tend to be useful in a multi-boot
situation.  It's likely that the same /tmp could be used for all *ix boots
anyway, whether that's 32-bit and 64-bit Gentoo, or Red Hat and Gentoo, or
even Solaris or one of the BSDs and Linux, provided you choose your
partition type appropriately.  Likewise with /home and possibly the stuff
in /usr/local, altho some *ix use that for more than Gentoo does.  You'd
likely wish to keep separate log partitions, of course.

The /l from my previous mail is /usr/local as well.  Here, I use the /l in
my paths and local settings, so it's the real mount-point and /usr/local
is the symlink to it, but that's purely personal preference.  Likewise
with /h and /home, only /h is the symlink since there's more system stuff
that's going to have /home in its default path.  I've done that with most
of the system dirs as well, so /u->/usr, /e->/etc, /usr/portage->/p,
/mnt->/m...

There are three dirs other than /tmp and /var/tmp that store non-critical
data.  These are /usr/src, which will normally contain the Linux kernel
sources and likely little else, and thus be easily redownloaded,
/usr/portage, with the easily resynced portage tree (and the $DISTDIR
subdir, package sources, automatically redownloaded if portage needs them
again), and for those of us running ccache, the portage ccache dir. 
I have all three of these symlinked to subdirs of a single RAID-0
partition on the same RAID-0 (but a different partition) as /tmp.  On a
single disk, you could either leave them in place or symlink them
similarly, to a single partition.  Note that these are all good candidates
for reiserfs even if you don't trust it with your valuable data (some
don't, as I said, I'm all reiserfs, but I have backup images of my
critical data), because the files tend to be small and reiserfs is more
efficient with small files than most fs, and because the data is
non-critical anyway. Therefore, even if you prefer ext3 or similar for
your critical data, putting these three on their own partition and making
it reiserfs is a good idea.

/pkg, my portage $PKGDIR, is its own partition as well (/p being already
taken, as the portage dir). Don't worry about this if you don't have
FEATURES=buildpkg set (make it 2-4 gig if you do, 1 gig minimum but that
requires cleaning up old package versions too often for comfort), but the
idea since I do, is to allow me to rebuild the system quickly from binary
packages (no recompiling from source), should I decide I need to for
whatever reason. Thus, keeping it off of the main system partition is a
good idea.

Purely due to personal use and preferences, I have separate /mail, /news,
and /mm (multimedia) partitions as well.  They'd normally subdirs of /home
or for mail and news, maybe subdirs of /var, but they tend to be big
enough to justify their own partitions, here, leaving /home to mainly
config settings and a few trivial files, and /var to system use.

There's a BIG potential gotcha once you start getting into double-digit
numbers of partitions, however.  IDE/PATA allows 64 partitions per device.
SCSI, and therefore libsata based SATA, only allows 16.  I moved directly
from PATA single drive, to SATA RAID, and avoided the problem, but had I
switched to single SATA instead of going RAID, I'd have had a problem due
to too many partitions, forcing me to choose to merge some of them.  On
PATA, I think I had 20, but that was before I combined /usr and /var onto
/, and combined ccache, /usr/src, and /pkg, into a single partition with
subdirs and symlinks to them.  I also had separate portage and DISTDIR at
the time; now  I don't.  I don't recall what the md kernel
driver partitioned RAID partition limit is, but it's high enough that with
the multiple RAID partitions on the physical drives, I don't have to
worry about it.  Even if I did, there's LVM, which I'm using in place of
partitioning where it makes sense, that is, for all my RAID-6 stuff other
than the root partition and its mirror (which are on separate partitions,
so I don't have to worry about an initrd/initramfs as I would with LVM
based roots, md works without an initrd/initramfs).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list