On Mon, Jan 12, 2009 at 03:54:41AM +0000, Arjan van de Ven wrote: > Jamie Lokier wrote: >> Arjan van de Ven wrote: >>>> - removing a million files and queuing all of the >>>> deletes in the async queues.... >>> the async code throttles at 32k outstanding. >>> Yes 32K is arbitrary, but if you delete a million files fast, all >>> but the first few thousand are >>> synchronous. >> >> Hmm. >> >> If I call unlink() a thousand times and then call fsync() on the >> parent directories covering files I've unlinked... I expect the >> deletes to be committed to disk when the last fsync() has returned. I >> require that a crash and restart will not see the files. Several >> kinds of transactional software and even some shell scripts expect this. >> >> Will these asynchronous deletes break the guaranteed >> commit-of-the-delete provided by fsync() on the parent directory? > > 3 things: > 1) removing the name from the directory and removing the data from disk are independent things. > The former happens from unlink(), the later happens when the refcount hits 0 (eg no more openers nor > any directory on disk referencing it). fsync() on a parent dir obviously only covers the first part, > while only the 2nd part was made asynchronous. > 2) with the right synchronization point in fsync, it will still work out What scope does that synchronisation point have? I sincerely hope you are not proposing to put a filesystem global synchronisation point into fsync.... > 3) this code will be redone for 2.6.30; for 2.6.29 it is removed. Can you tell use how you plan to redo this code and test it adequately for 2.6.30? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- 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
