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

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.


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.120 / U:1.536 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site