On Thu, Oct 02, 2014 at 01:31:23PM +0200, Christoph Hellwig wrote: > On Thu, Oct 02, 2014 at 08:26:37AM +1000, Dave Chinner wrote: > > On Wed, Oct 01, 2014 at 11:04:51PM +0200, Christoph Hellwig wrote: > > > Hi Miklos, > > > > > > attached are the patches that go on top of your > > > "[RFC v3 0/4] vfs: Non-blockling buffered fs read (page cache only)" > > > series. The first one adds RWF_NONBLOCK to XFS, the other two > > > add a new RWF_DSYNC flag that adds a per-operation O_DSYNC flag. > > > > Christoph, any plans to add these new syscalls to xfs_io and > > data integrity tests for the new RWF_DSYNC flag? > > I've got some hacked up xfs_io support, but Milosz was planning a > slight revision of the syscall interface that I'm still waiting for. > > How would you want to automatically test for data integrity? That requires > a powerfail or crash unfortunately and we don't have good infrastructure > for that yet. I've tested it by adding a printk that RWF_DSYNC triggers > the same code path as O_DSYNC. We have the infrastructure in xfstests to do this in a generic way: use dm-flakey. The fsync tests (generic/311, generic/32[23]) that Josef wrote that use dm-flakey to prevent writes after the IOs have completed and check that the data is there after remount. Similarly, for xfs specific tests we have older tests that use the shutdown ioctl (e.g. xfs/137-139) by using the godown function to shut the filesystem down and prevent unmount from writing metadata. On remount the data should be present. So there's a couple of different ways you can do this... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs