Chris Mason wrote:
>
> For the most part, reiserfs can play nice with bdflush. I give it blocks
> when I've decided they are ready to get to disk, and I keep blocks away
> from it when they aren't allowed to be written.
But why not give them straight to ll_rw_block? Maybe the real question
is, where does the elevator scheduling happen, in ll_rw_block or in
bdflush? I haven't checked.
> There have been threads on i/o ordering recently, and that would really
> clean things up. Stephen, I'm assuming you have io ordering in mind for
> your queue of 2.5 changes, I'm more than willing to help code something.
I/O ordering constraints are complex for journalling filesystems, simple
for Tux2. Tux2 blocks are always partitioned into two groups, plus two
metaroots for ordering purposes, and the relationship is simple: write
all of the first group; then its metaroot; let the second group become
the first group; wait for a new second group to appear; repeat as
necessary. No outside mechanism is needed to assist this.
> > What we need is a sensible method/callback/library arrangement for the
> > sync like we now have for read/write/mmap. What we have now is far from
> > sensible. Syncing should be done one superblock at a time, not across
> > the entire system like it is now. IOW, it's currently sliced
> > horizonally while it really needs to be sliced vertically. We need need
> > a sync_filesystem method and it should default to a generic_sync_super
> > that does the current dumb sync. You should then put your improvements
> > in as a method override, not just make the current messy arrangement
> > even messier.
>
> I don't entirely disagree, but reiserfs could actually sync slower if it
> was done an FS at a time. write_super will commit the current transaction,
> which will dirty a whole bunch of metadata buffers for writing. So, by
> calling write_super on every FS first, you have the chance to make better
> use of the underlying devices.
I don't see how you make better use of anything. I'm not suggesting
you're wrong, I'm just need to ask in what why something is making
better use of something else. And aren't you giving support to what I
just said? We need to make the sync a method so that you can do your
strange things, I can do mine, and dumb filesystems can just continue
being dumb.
Perhaps the best thing to do is to make wonderful, private patches that
do various exotic things to the VFS to make life easier for ourselves,
then roll them out so the world can see how elegant they are, instead
trying to convince Al and friends to patch up the existing kernel now,
which they seem understandably reluctant to do. You're out-of-kernel
right now anyway, so why not get agressive and do exactly the things you
need to do to the VFS, without bothering to ask? Or maybe that's what
you're already doing :-)
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
