On Tue, 23 Sep 2014 10:46:58 +0200, Andreas Rohner wrote: > Support for fdatasync() has been implemented in NILFS2 for a long time, > but whenever the corresponding inode is dirty the implementation falls > back to a full-flegded sync(). Since every write operation has to update > the modification time of the file, the inode will almost always be dirty > and fdatasync() will fall back to sync() most of the time. But this > fallback is only necessary for a change of the file size and not for > a change of the various timestamps. > > This patch adds a new flag NILFS_I_INODE_SYNC to differentiate between > those two situations. > > * If it is set the file size was changed and a full sync is necessary. > * If it is not set then only the timestamps were updated and > fdatasync() can go ahead. > > There is already a similar flag I_DIRTY_DATASYNC on the VFS layer with > the exact same semantics. Unfortunately it cannot be used directly, > because NILFS2 doesn't implement write_inode() and doesn't clear the VFS > flags when inodes are written out. So the VFS writeback thread can > clear I_DIRTY_DATASYNC at any time without notifying NILFS2. So > I_DIRTY_DATASYNC has to be mapped onto NILFS_I_INODE_SYNC in > nilfs_update_inode(). > > Signed-off-by: Andreas Rohner <andreas.rohner@xxxxxxx> I now sent this to Andrew. The datasync segments that this patch creates more frequently, will cause rollforward recovery after a crash or a power failure. So, please test also that the recovery works properly for fdatasync() and reset. The situation can be simulated, for example, by using "reboot -nfh": # dd if=/dev/zero of=/nilfs/test bs=4k count=1 seek=9999 # dd if=/dev/urandom of=/nilfs/test bs=8k count=1 seek=50 conv=fdatasync,notrunc,nocreat # reboot -nfh We can use dumpseg command to confirm that the datasync segment is actually made or how recovery has done after mount. Thanks, Ryusuke Konishi -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
