Messages in this thread | | | Date | Mon, 15 Feb 1999 19:36:30 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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/
| |