First off, I acknowledge I am a newbie to this list,
so
I have donned my Armor of Ignorance, my Shield of
Utter Cluelessness and my +3 Ring of Invisibility.
(Yesssssss, my precioussssss... Gollum!)
Anyways, it seems to me that the arguments over the
addition of a journalled file system are a little OTT,
so I thought I'd throw my 2 ECU's worth in, in case it
might help cool things off just a tad.
First off, this has probably already been done, but I
will do it anyway, and propose an Abstract Journal
Layer (AJL). This would be a light-weight layer, which
provided a sufficient and complete abstract API to the
different journalling systems.
Filesystems MUST have provisions to access the AJL,
but
may also access ANY number of journalling systems
using
the journal's native API. The user can specify a
method
when a partition is mounted, or a default of the
method
used to create the filesystem will be used.
Journals MUST have provisions to be accessed via the
AJL, either passively or actively. They may also
optionally make their "native" API open to filesystems
to access directly.
Passive connections to the AJL would be through a
light-weight interface in the journal code. This would
process the AJL requests directly in the journal.
Active connections to the AJL would be through loading
a driver into the AJL, through the regular driver
mechanism. This would allow pre-processing of the
request(s) in the AJL itself. (This would be useful,
say, if you had a file mounted as a loopback device,
using a journalling file system, where the file itself
was in another journalling file system. An active
module could ensure that both layers were in sync over
what had been saved and what hadn't.)
What does this do, for us, both in terms of the
technology and in terms of meeting the various
arguments put forward on the list?
First, it meets Alan Cox' concern that there would be
redundant code/data in the kernel. By allowing the
journal and the FS to be seperated this way, the user
would only have the journals they explicitly want in
memory.
Secondly, it meets Hans Reiser's concern that ReiserFS
has the "best" code in town. By retaining a provision
of a direct interface, it's not going to be impaired
by
any other provisions.
Thirdly, it meets Hans Reiser's concern of having code
by committee. By allowing users to mix and match, the
code that's best will evolve and the rest will die, in
the way it always does in Free Software.
Fourthly, it meets the technical problem of
journalling
across RAID. The AJL would provide a mechanism by
which
the individual drives AND/OR the filing system can be
journalled in a consistant way, across the entire
drive
array.
Lastly, it seperates the journal from the FS, which
means that ANY FS can use ANY journal, irrespectively
of what journal it was designed for. The AJL will make
the alternative journalling system look like the one
it
expects. This means that people can experiment with
the
different journalling systems, and see how performance
is affected with different combinations, over
different
types of data. Something that currently cannot be
done,
because everything's so tightly coupled.
As I said, these are thoughts probably everyone else
has had, already, but you never know. It's possible
that there's a slightly different perspective here,
that might spark off a few interesting thoughts.
jd
p.s. InactiveFireproofX attachments not included.
Please add your own.
__________________________________________________
Do You Yahoo!?
Yahoo! Photos -- now, 100 FREE prints!
http://photos.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:25 EST