On Fri, Aug 04, 2006 at 06:31:49PM -0700, Andrew Morton wrote: > > Could we have more detail on what you're trying to do here? > > You've obviously made some decisions about how to handle under-writeback > data, dirty data, integrity versus cleaning, etc. What were those > decisions and what led you to them? The basic idea is that someone watching the blinking light on the usb stick knows that when the light goes out, he can pull the stick out. It's an alternative to mount -o sync that it closer to what users are asking for. There's no attempt at integrity, it only tries to keep a fairly constant flow of data to the device. > > We should document the precise semantics of these two functions, especially > wrt data integrity, handling of dirty-but-under-writeback pages, etc. > (Right now I'm not sure what those semantics are). They are loosely defined. One way to handle dirty-but-under-writeback pages is to add a timer that filemap_fdatawrites the block device. Since fdatawrite is used in the file release call, regular files don't need this, only the block device. This timer isn't added in the patch, but it's an easy addition later. > > I'm also wondering what sync_inode(nr_to_write=0) does ;) I think it writes > one page... It starts a write on the inode and nothing else ;) There are lots of ways to write the inode and wait, but this was the only one I found to write the inode without waiting and then write the data pages while waiting for in flight io. -chris - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html