linux-kernel - Re: [PATCH] async: Don't call async_synchronize_full_special() while holding sb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 12 Jan 2009 18:55:16 +1100
From:	Dave Chinner <david@...morbit.com>
To:	Arjan van de Ven <arjan@...ux.intel.com>
Cc:	Jamie Lokier <jamie@...reable.org>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Grissiom <chaos.proton@...il.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] async: Don't call async_synchronize_full_special()
	while holding sb_lock

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@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/