lkml.org 
[lkml]   [1999]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site