On Wed, Jan 21, 2009 at 04:59:21AM +0000, Jamie Lokier wrote: > Nick Piggin wrote: > > This is just another reason why I prefer to just try to evolve the > > traditional fsync interface slowly. > > But sync_file_range() has a bug, which you've pointed out - the > missing _data-retrieval_ metadata isn't synced. In other words, it's > completely useless. I don't know. I don't think this is a newly discovered problem. I think it's been known for a while, so I don't know what's going on. > If that bug isn't going to be fixed, delete sync_file_range() > altogether. There's no point keeping it if it's broken. And if it's > fixed, it'll do what your fsync_range() does, so why have both? Well the thing is it doesn't. Again it comes back to the whole writeout thing, which makes it more constraining on the kernel to optimise. For example, my fsync "livelock" avoidance patches did the following: 1. find all pages which are dirty or under writeout first. 2. write out the dirty pages. 3. wait for our set of pages. Simple, obvious, and the kernel can optimise this well because the userspace has asked for a high level request "make this data safe" rather than low level directives. We can't do this same nice simple sequence with sync_file_range because SYNC_FILE_RANGE_WAIT_AFTER means we have to wait for all writeout pages in the range, including unrelated ones, after the dirty writeout. SYNC_FILE_RANGE_WAIT_BEFORE means we have to wait for clean writeout pages before we even start doing real work. -- 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
