[gentoo-dev] Re: Re: grub reiser4

[Duncan <1i5t5.duncan@cox.net>]

Chris Bainbridge posted <623652d50510021043g6a4a9fd6n@mail.gmail.com>,
excerpted below,  on Sun, 02 Oct 2005 17:43:04 +0000:

> On 02/10/05, Dan Meltzer <parallelgrapefruit@gmail.com> wrote:
>> On 10/2/05, Chris Bainbridge <chris.bainbridge@gmail.com> wrote:
>> > On 02/10/05, Alec Warner <warnera6@egr.msu.edu> wrote:
>> > > Chris Bainbridge wrote:
>> > > > On 02/10/05, R Hill <dirtyepic.sk@gmail.com> 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