Messages in this thread | | | Date | Mon, 15 Feb 1999 20:08:41 -0500 (EST) | From | "Theodore Y. Ts'o" <> | Subject | Re: fsync on large files |
| |
From: torvalds@transmeta.com (Linus Torvalds) Date: 15 Feb 1999 18:52:59 GMT
I'd much prefer a much more aggressive patch, that just made the dirty lists a per-inode thing. It shouldn't be too hard - just add the inode as a parameter to "mark_block_dirty()".
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.
I can also remove the N**2 aspect of inserting into the list by keeping the list sorted, and then using a binary search to check for the existence of the block on the list, and then do a sorted insert into the 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?
- Ted
- 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/
| |