If you're referring to the COUCHDB-767 discussion, I don't think it was ever resolved. I don't want to revert the patch unless there is an operating system somewhere on which it actually results in reduced durability. I agree that it's icky to be relying on a property of fsync() that is apparently not guaranteed by any specification, but it sucks to block readers just to flush disk buffers.
As an aside, I'm having trouble reconciling Tso's statement in http://www.spinics.net/lists/linux-ext4/msg21388.html with the following from SUS v2: > The fsync() function forces all currently queued I/O operations associated > with the file indicated by file descriptor fildes to the synchronised I/O > completion state. It doesn't say I/O operations associated with the file descriptor, it says I/O operations associated with the file. But far be it from me to question his interpretation of the spec; he's written more filesystems than I've used in production. Best, Adam On Nov 12, 2010, at 2:47 PM, Mikeal Rogers wrote: > I'm a little late to this party. > > The discussion about reverting a commit that may have interfered without > fsync guarantees, did that go in for 1.0.2? > > That's an important bug that I would like to see in 1.0.2. > > -Mikeal > > On Fri, Nov 12, 2010 at 11:40 AM, Filipe David Manana > <[email protected]>wrote: > >> I'm totally +1 on 1.0.2 asap. >> >> On Fri, Nov 12, 2010 at 7:21 PM, Dirkjan Ochtman <[email protected]> >> wrote: >>> On Wed, Nov 3, 2010 at 18:06, Filipe David Manana <[email protected]> >> wrote: >>>> and done >>> >>> Oh, look, I'm back for more nagging! How are we doing on 1.0.2? Or >>> 1.1, for that matter, just any release that gets me the good stuff >>> you've all been working on. >>> >>> Cheers, >>> >>> Dirkjan >>> >> >> >> >> -- >> Filipe David Manana, >> [email protected], [email protected] >> >> "Reasonable men adapt themselves to the world. >> Unreasonable men adapt the world to themselves. >> That's why all progress depends on unreasonable men." >>
