mkdir and fsync

mkdir and fsync

[Samer Al-Kiswany]

Hi,

Thank you for help.

I am seeing a strange behavior when fsync()ing a directory.

Here is what I do

for (i=0; i < 100,000, i++){
	.
      mkdir(p/child_i)
      fsync(p)
}

Btrfs seems to achieve around 100k fsycs/second, which makes me believe it
is not touching the disk during these fsyncs.
After looking at the code, it seems indeed that fsync adds the inode to the
current transaction but does not sync the transaction to disk.

Is this the intended behavior for metadata fsync or is this a bug?
Is this POSIX compliant?

Thank you for your help
-samer

Re: mkdir and fsync

[Christoph Hellwig]

On Wed, Sep 10, 2014 at 01:55:35PM -0700, Samer Al-Kiswany wrote:
> Btrfs seems to achieve around 100k fsycs/second, which makes me believe it
> is not touching the disk during these fsyncs.
> After looking at the code, it seems indeed that fsync adds the inode to the
> current transaction but does not sync the transaction to disk.
> 
> Is this the intended behavior for metadata fsync or is this a bug?
> Is this POSIX compliant?

Posix is basically meaningless for fsync:

    The fsync() function shall request that all data for the open file
    descriptor named by fildes is to be transferred to the storage
    device associated with the file described by fildes. The nature of
    the transfer is implementation-defined. The fsync() function shall
    not return until the system has completed that action or until an
    error is detected.

    [SIO] [Option Start] If _POSIX_SYNCHRONIZED_IO is defined, the
    fsync() function shall force all currently queued I/O operations
    associated with the file indicated by file descriptor fildes to
    the synchronized I/O completion state. All I/O operations shall
    be completed as defined for synchronized I/O file integrity
    completion. [Option End]

but Linux semantics do expect a filesystem to write out all metadata for
a directory file descriptor on a fsync.

Re: mkdir and fsync

[Chris Mason]

On 09/10/2014 04:55 PM, Samer Al-Kiswany wrote:
> Hi,
> 
> Thank you for help.
> 
> I am seeing a strange behavior when fsync()ing a directory.
> 
> Here is what I do
> 
> for (i=0; i < 100,000, i++){
> 	.
>       mkdir(p/child_i)
>       fsync(p)
> }
> 
> Btrfs seems to achieve around 100k fsycs/second, which makes me believe it
> is not touching the disk during these fsyncs.
> After looking at the code, it seems indeed that fsync adds the inode to the
> current transaction but does not sync the transaction to disk.
> 
> Is this the intended behavior for metadata fsync or is this a bug?
> Is this POSIX compliant?

Which kernel and hardware?  We had some dir fsync handling bugs in the
past which may have been related.

I just did a test here, and we're definitely doing the IO.  Christoph is
right about the requirements for fsync being sloppy.  For btrfs, we do
put directory changes into the log during an fsync, but we may end up
logging only what you fsync.

So this will get child_i:

mkdir(p/child_i)
fsync(p)

This will not:

mkdir(p/child_i)
fsync(some_other_directory_that_isn't_p)

(This is different from ext34)

-chris

RE: mkdir and fsync

[Samer Al-Kiswany]

Thank you Chris,

We use kernel 3.2 in a virtual machine using VirtualBox. We will test it
with the latest kernel version and let you know if we face the same issue.

Thank you
-samer
http://www.ece.ubc.ca/~samera/ 
http://www.cs.wisc.edu/~samera/ 


-----Original Message-----
From: Chris Mason [mailto:clm@fb.com] 
Sent: Thursday, September 11, 2014 6:29 AM
To: Samer Al-Kiswany; linux-btrfs@vger.kernel.org
Subject: Re: mkdir and fsync

On 09/10/2014 04:55 PM, Samer Al-Kiswany wrote:
> Hi,
> 
> Thank you for help.
> 
> I am seeing a strange behavior when fsync()ing a directory.
> 
> Here is what I do
> 
> for (i=0; i < 100,000, i++){
> 	.
>       mkdir(p/child_i)
>       fsync(p)
> }
> 
> Btrfs seems to achieve around 100k fsycs/second, which makes me 
> believe it is not touching the disk during these fsyncs.
> After looking at the code, it seems indeed that fsync adds the inode 
> to the current transaction but does not sync the transaction to disk.
> 
> Is this the intended behavior for metadata fsync or is this a bug?
> Is this POSIX compliant?

Which kernel and hardware?  We had some dir fsync handling bugs in the past
which may have been related.

I just did a test here, and we're definitely doing the IO.  Christoph is
right about the requirements for fsync being sloppy.  For btrfs, we do put
directory changes into the log during an fsync, but we may end up logging
only what you fsync.

So this will get child_i:

mkdir(p/child_i)
fsync(p)

This will not:

mkdir(p/child_i)
fsync(some_other_directory_that_isn't_p)

(This is different from ext34)

-chris