Chris Bainbridge posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 02 Oct 2005 17:43:04 +0000:
> On 02/10/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: >> On 10/2/05, Chris Bainbridge <[EMAIL PROTECTED]> wrote: >> > On 02/10/05, Alec Warner <[EMAIL PROTECTED]> wrote: >> > > Chris Bainbridge wrote: >> > > > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: >> > > >>I still think it's retarded to have a reiser 4 boot partition, but >> > > >>whatever stirs your pot. ;P >> > > > >> > > > It makes sense if you're actually using reiser4 for everything >> > > > else. Why bloat your kernel with an extra FS just for /boot? >> In addition, why bloat your fs by having a journaled filesystem for >> essentially static files? > > Because it's easier to have a single fs for / than have multiple > partitions, and try to isolate all of the things that are "essentially > static" and move them over to unjournalled file systems. Journalling > operations on /boot are responsible for filling a very, very small > percentage of my hard disk. I'm doing this with reiserfs (3) ATM. 100% reiserfs system, fat and ext2 as kernel modules that I load only in the rare event I'm going to access a floppy. I have 20 partitions, including /boot and some others that are normally static, and /tmp and my portage tree and source partitions that are temporary or redownloadable so they really don't need journalled. However, the disk is some 250 GB, out of which well over 100 GB remains entirely unformatted at this point, so journal space isn't an issue, and it's simply less bother keeping everything on reiserfs, even on partitions where the default journal is a rather large portion of the entire partition, than otherwise. Note that reiser4 is "wandering journal". As I understand it, it doesn't set up a dedicated journal space, but rather, journals on the fly, by rewriting a file then cascading the metadata entries up the (duplicated) tree branch until it reaches the root entry, at which point the commit goes final as the old metadata tree branch is discarded and the new one takes effect. This isn't journalling, but rather, atomic metadata entry. Thus, there *IS* no journal per se, simply half finished commits that haven't gotten all the way up the tree to the root entry yet. The change is either fully committed or not committed at all, so unless the crash occurs at the exact moment the root entry itself is being updated (and I believe there's a special case for it, accounting for that very possibility), there's simply nothing to journal. Half-written commits that didn't fully cascade all the way to the top will simply be pruned in the event of recovery. The system is fully atomic, no journal necessary. Thus (unless I've misunderstood what I've read of reiser4), journal space isn't an issue with reiser4. It's an atomic transaction system, rather than a journal. That's also one of the reasons why copy method affects access time. Untar a tarball not created on reiser4 onto a reiser4 system, and those files won't be laid out for optimum access efficiency. That was one of the points Hans made in some of the benchmarking attempts. I don't quite understand the implications here, but apparently, taking the newly expanded files, copying (not moving) them elsewhere on the reiser4 system, deleting the old copy, then copying them back (if necessary), will reoptimize the layout into reiser4-access-optimized. Alternatively, running the repacker reoptimizes the entire fs, as well. Obviously, I've been following reiser4 with some interest, altho I've stuck with reiser3 to this point. (reiser4 has been unstable on amd64, I've been told.) That may change in the next few months, however, as I'll probably get a new disk (I've lots of space left, but this one has some badblocks due to overheating during an A/C malfunction) and am considering taking the opportunity to transfer to reiser4. -- 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-dev@gentoo.org mailing list
