Re: [PATCH] async: Don't call async_synchronize_full_special() while holding sb_lock

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com