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
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
