Yes.
> list. What I'm currently thinking about is to make the filesystem
> allocate memory for storing the dirty list, and allow the filesystem
> decide what an appropriate number of blocks to allow to be stored in the
> dirty list. Most files never have fsync() called upon them, so a way we
> can make things efficient is to only create the dirty list after the
> first call to fsync() on an inode. The first fsync() can then either go
> through all of the indirect blocks, or cause a forced fsync_dev if that
> would be more efficient. That way, for files which don't get
> fsync()'ed, we don't have the overhead of keeping and maintaining the
> dirty list.
>
> Does this sound like a reasonable design?
Ugh.
I'd much rather just always add it to the "inode dirty list". List
maintenance is essentially zero overhead if you use the nice list macros
in <linux/list.h> (as opposed to the braindamaged BSD compatibility macros
in <linux/lists.h>), and it's fairly trivial to just keep each dirty block
on two dirty lists (one inode-specific, one global - you'd still use the
global one for normal write-outs).
It's just a few pointer operations, and the advantage of having a clean
and simple design probably results in better performance anyway.
Linus
-
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/