On Tue, Apr 22, 2014 at 02:28:37AM -0700, Christoph Hellwig wrote: > On Tue, Apr 22, 2014 at 08:04:21AM +0100, Jamie Lokier wrote: > > Hi Christoph, > > > > Hardly research, I just did a quick Google and was surprised to find > > some results. AIX API differs from the BSDs; the BSDs seem to agree > > with each other. fsync_range(), with a flag parameter saying what type > > of sync, and whether it flushes the storage device write cache as well > > (because they couldn't agree that was good - similar to the barriers > > debate). > > There is no FreeBSD implementation, I think you were confused by FreeBSD > also hosting NetBSD man pages on their site, just as I initially was. > > The APIs are mostly the same, except that AIX reuses O_ flags as > argument and NetBSD has a separate namespace. Following the latter > seems more sensible, and also allows developer to define the separate > name to the O_ flag for portability. > > > As for me doing it, no, sorry, I haven't touched the kernel in a few > > years, life's been complicated for non-technical reasons, and I don't > > have time to get back into it now. > > I've cooked up a patch, but I really need someone to test it and promote > it. Find the patch attached. There are two differences to the NetBSD > one: ..... > From b63881cac84b35ce3d6a61a33e33ac795a5c583c Mon Sep 17 00:00:00 2001 > From: Christoph Hellwig <hch@xxxxxx> > Date: Tue, 22 Apr 2014 11:24:51 +0200 > Subject: fs: implement fsync_range Christoph, if this is going into the kernel, can you add support for xfs_io and write a couple of xfstests to test it? I'm not comfortable with adding new data integrity primitives to the kernel without having robust validation infrastructure already in place for it. It might also be worthwhile looking to extend Josef's fsync-tester.c to be able to use ranged fsyncs so to test all the various corner cases that we need to.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
