Andrew Morton <akpm@xxxxxxxx> writes: >> 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. > > Yes. I think it would not be desirable it depends a LED, because some devices doesn't have a LED. (e.g. MMC/SD, MS, etc.) >> 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. > > It's a data-integrity operation, because we want that filesystem to be in > good shape after the LED goes off. Not after a pdflush interval of 30 > seconds. > > Consequently the semantics which we require of the library functions which > you've added should be: > > /* > * On return from this function all dirty data has been cleaned - it is either > * on disk or is in flight in the I/O queues. > */ > > These semantics are exactly provided by > do_sync_file_range(SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE). > I'd suggest that do_sync_file_range() could be used to sync the file's > data in this application, if only for reasons of clarity and precision. > > That leaves the file metadata, the inode itself and the superblock, for > which we'd ideally likely same semantics, but stronger sync semantics would > of course meet our requirement. > > metadata: we don't have an > SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE implementation of > fsync_buffers_list() so unless we add such, we need to use > fsync_buffers_list()'s > (SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE|SYNC_FILE_RANGE_WAIT_AFTER) > semantics. I'd suggest a call to sync_mapping_buffers() directly. > > The inode: write_inode_now(wait=0) will I think be appropriate here. > > superblock: it's possible that the proposed three-step scheme will leave > the filesystem's superblock unwritten. Need to think about that. Yes, the superblock is problem. And for it, I'm thinking to add new "autorw" option. autorw changes `ro' to `rw' automatically on first write operation. The daemon is watching it in userland. And it'll change option from `rw' to `ro' by remount. With remount, filesystem will flush all dirty data, and marks it as clean. So, if filesystem is `ro', user can unplug device. But, I still don't know whether this works fine or not. If it works, I'm thinking very very simple "flush" option would be enough. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> - 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
