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:[email protected]] Sent: Thursday, September 11, 2014 6:29 AM To: Samer Al-Kiswany; [email protected] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
