[lkml]   [1999]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: fsync on large files
       From: (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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:50    [W:0.019 / U:51.752 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site