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    [W:0.021 / U:155.232 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site