Re: Ordering of directory operations maintained across system crashes in Btrfs?

[Chris Mason <clm@fb.com>]

On 02/25/2014 09:01 PM, thanumalayan mad wrote:
> Hi all,
>
> Slightly complicated question.
>
> Assume I do two directory operations in a Btrfs partition (such as an
> unlink() and a rename()), one after the other, and a crash happens
> after the rename(). Can Btrfs (the current version) send the second
> operation to the disk first, so that after the crash, I observe the
> effects of rename() but not the effects of the unlink()?
>
> I think I am observing Btrfs re-ordering an unlink() and a rename(),
> and I just want to confirm that my observation is true. Also, if Btrfs
> does send directory operations to disk out of order, is there some
> limitation on this? Like, is this restricted to only unlink() and
> rename()?
>
> I am looking at some (buggy) applications that use Btrfs, and this
> behavior seems to affect them.

There isn't a single answer for this one.

You might have

Thread A:

ulink(foo);
rename(somefile, somefile2);
<crash>

This should always have the rename happen before or in the same 
transaction as the rename.

Thread A:

ulink(dirA/foo);
rename(dirB/somefile, dirB/somefile2);

Here you're at the mercy of what is happening in dirB.  If someone 
fsyncs that directory, it may hit the disk before the unlink.

Thread A:

ulink(foo);
rename(somefile, somefile2);
fsync(somefile);

This one is even fuzzier.  Backrefs allow us to do some file fsyncs 
without touching the directory, making it possible the unlink will hit 
disk after the fsync.

-chris