--On 10/06/00 21:05:30 +0200 Daniel Phillips <[EMAIL PROTECTED]> wrote:
> Chris Mason wrote:
>> > So I have the priorty ordering:
>> >
>> > blocks(i) -> root(i) -> blocks(i+1) -> root(i+1) -> etc
>> >
>> > And it would be possible to compress that slightly to:
>> >
>> > root(i-1) + blocks(i) -> root(i) + blocks(i+1) -> etc
>>
>> Then the io borders would benefit you as well. Anywhere you
>> wait_on_buffer because that buffer has to hit disk before you can
>> proceed is a performance hit. It won't fix many book keeping problems,
>> but it will make it easier to keep things flowing to disk.
>
> 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).
>> 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.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
