Messages in this thread | | | Date | Mon, 15 Feb 1999 17:46:42 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: fsync on large files |
| |
On Mon, 15 Feb 1999, Theodore Y. Ts'o wrote: > > So you mean moving the dirty list into the filesystme-generic portion of > the inode structure, instead of being an ext2-specific hack? That seems > quite reasonable.
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/
| |