Hi,
At 12:02 07/08/01, Stephen C. Tweedie wrote:
>On Mon, Aug 06, 2001 at 11:18:26PM +0200, Daniel Phillips wrote:
>FWIW, we've seen big performance degradations in the past when testing
>different ext3 checkpointing modes. You can't reuse a disk block in
>the journal without making sure that the data in it has been flushed
>to disk, so ext3 does regular checkpointing to flush journaled blocks
>out. That can interact very badly with normal VM writeback if you're
>not careful: having two threads doing the same thing at the same time
>can just thrash the disk.
>
>Parallel sync() calls from multiple processes has shown up the same
>behaviour on ext2 in the past. I'd definitely like to see at most one
>thread of writeback per disk to avoid that.
Why not have a facility with which each fs can register their own writeback
functions with a time interval? The daemon would be doing the writing to
the device and would be invoking the fs registered writers every <time
interval> seconds. That would avoid the problem of having two fs trying to
write in parallel but that ignores the problem of having two parallel
writers on separate partitions of the same disk but that could be solved at
the fs writeback function level.
At least for NTFS TNG I was thinking of having a daemon running every 5
seconds and committing dirty data to disk but it would be iterating over
all mounted ntfs volumes in sequence and flushing all dirty data for each,
thus avoiding concurrent writing to the same disk, which I had thought
might cause a problem and you just confirmed it...[1]
Just a thought,
Anton
[1] I am aware this probably doesn't scale too well but considering a
volume can span several disk partitions on the same disk or across several
disks I don't see how to parallelize at the fs level.
-- "Nothing succeeds like success." - Alexandre Dumas -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:44 EST