On Sat, Dec 25, 2010 at 9:41 PM, Olaf van der Spek <olafvdspek@xxxxxxxxx> wrote: > On Sat, Dec 25, 2010 at 4:15 AM, Ted Ts'o <tytso@xxxxxxx> wrote: >> On Fri, Dec 24, 2010 at 12:14:21PM +0100, Olaf van der Spek wrote: >>> >>> Thanks for taking the time to answer. The thread was started due to >>> the dpkg issue. >> >> I've talked to the dpkg folks and I believe they are squared away; for >> their use case sync_file_range() combined with fsync() should solve >> their reliability and performance problem. > > It's not just about dpkg, I'm still very interested in answers to my > original questions. Arbitrary atomic but non-durable file write operation? That's significantly different to how any part of the pagecache or filesystem or syscall API is set up. Writes are not atomic, and syncs are only for durability (not atomicity), atomicity is typically built on top of these durable points. That is quite fundamental functionality and suits simple implementations of filesystems and writeback caches. If you start building complex atomicity semantics, then you get APIs which can't be supported by all filesystems, Linux specific, adds complexity from the API through to the pagecache and to the filesystems, and is Linux specific. Compare that to using cross platform, mature and well tested sqlite or bdb, how much reason do we have for implementing such APIs? It's not that it isn't possible, it's that there is no way we're adding such a thing unless it really helps and is going to be widely used. What exact use case do you have in mind, and what exact API semantics do you want, anyway? -- 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
