David Guerizec posted <[EMAIL PROTECTED]>, 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 -- [email protected] mailing list
