Chris Mason wrote:
> > Ah, I see. I was assuming I'd sleep until the I/O completion, wake up
> > and instantly handle the metaroot I/O start, sleep again and wake up to
> > do the next phase transition. Actually, I don't see why that wouldn't
> > work.
>
> It will work, just not as fast as the borders will ;-) Especially on scsi,
> where the borders could just use the command tags (I heard Andre had a ide
> tag patch floating around too). Instead of sleeping, you just put up a
> border to force blocks(i) to disk before root(i).
What makes the border work faster than me waking up on I/O completion?
Ah, o, I see, I can preprogram the priority constraints into the scsi
controller. This is black magic to me, can you give me a pointer? And
what about dumb old ide?
> >> Ok, as long as we understand why the current method is good, we can talk
> >> about ways to make it better ;-) Instead of forking a thread for each
> >> sync, I would rather allow the FS to start a thread on mount, and use
> >> that for syncing. Either way, it is something that could be
> >> experimented with, to see if the cost/complexity is worth it.
> >
> > Interestingly, that's exactly what I do. It's called "tuxdemon". It
> > already has to have some way to know when to quit - it watches a
> > variable that gets set during [the regular close-down sequence]. It
> > sounds promising, *but*, what about those file systems that are content
> > to let bdflush do their dirty work (groan) for them? Why have a couple
> > dozen extra threads just for them? I know it's not much overhead to
> > have a sleeping thread around, but still...
>
> It is probably better to use tux2 as an example for starters. Show the
> benefit of the change, and then we can fight out how to do it for the other
> filesystems. If anyone else is going to need something special here, it is
> probably GFS, so you might want to hunt down the sistina folks next week.
Tux2 has no choice but to do this. The question is, how can this be
generalized? I suspect that bdflush could substitute for tuxdemon if it
weren't so confident it knew what to do...
--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
