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


    On Mon, 15 Feb 1999, Theodore Y. Ts'o wrote:
    > global one for normal write-outs).
    >
    > This works for ext2, but it doesn't work with filesystems (most notably
    > FAT filesystems, and possibly some B-tree based filesystems) where
    > metadata might be shared by multiple files, so a block might have to be
    > on multiple inode dirty lists.

    Note that even ext2 has this kind of dirty blocks: the inode blocks
    themselves.

    I think they should just be considered separate, and "write_inode()" or
    the file-system-specific "fsync()" function or whatever should take care
    of those kinds of blocks (ie the VFS layer wouldn't care - it would only
    write out the "inode-exclusive" dirty blocks).

    > I had thought about using a linked list
    > architecture and threading buffer_head structures onto inode dirty
    > linked lists, but I discarded that plan since it wouldn't work for all
    > filesystems.

    I think that just sounds too complicated. A filesystem that has lots of
    shared dirty blocks is going to have a slow and complex fsync(), but I
    think it's fairly simple to just consider the exclusive blocks a separate
    issue, and then just accept the fact that there are shared data structures
    that have to be maintained separately by the filesystem.

    Just having an exclusive dirty list would make 99% of all fsync() issues
    just go away. The remaining 1% is not likely to be a real problem, imho,
    and is very obviously not something that the VFS layer can really help
    with anyway.

    (Think FFS, for example: the extent block obviously would have to be
    handled by FS-specific code, there's no point in trying to teach the VFS
    layer about these things. So it's not even just metadata that can be in
    shared blocks).

    Note that a per-inode dirty list is certainly not the only way to handle
    this issue. We could go a separate approach, with a "web of dependencies"
    kind of thing, and "fsync()" would just become something that traverses
    the dependencies in some order. For ext2 you could have something like

    - inode depends on the following:
    - inode buffer
    - direct data blocks
    - indirect block
    - data blocks
    - doubly indirect block
    - indirect block
    - data blocks

    and then actually have these dependencies as dependency lists in the data
    structures themselves. The above would handle "shared data" by simply
    having the same block on multiple dependency lists. But the above is just
    a _lot_ more complex, too, which is why I'd prefer a simpler per-inode
    exclusive dirty list + some low-level FS logic for the rest.

    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/

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