On Thu, 6 Aug 2015, Christoph Hellwig wrote: > On Wed, Aug 05, 2015 at 02:26:30PM -0700, Sage Weil wrote: > > Today I learned that syncfs(2) does an O(n) search of the superblock's > > inode list searching for dirty items. I've always assumed that it was > > only traversing dirty inodes (e.g., a list of dirty inodes), but that > > appears not to be the case, even on the latest kernels. > > I'm pretty sure Dave had some patches for that, Even if they aren't > included it's not an unsolved problem. > > > The main thing to watch out for is that according to POSIX you really need > > to fsync directories. With XFS that isn't the case since all metadata > > operations are going into the journal and that's fully ordered, but we > > don't want to allow data loss on e.g. ext4 (we need to check what the > > metadata ordering behavior is there) or other file systems. > > That additional fsync in XFS is basically free, so better get it right > and let the file system micro optimize for you. I'm guessing the strategy here should be to fsync the file (leaf) and then any affected ancestors, such that the directory fsyncs are effectively no-ops? Or does it matter? Thanks! sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
