On Fri, 2008-12-19 at 12:08 -0800, Sage Weil wrote: [ trigger data=ordered flush at commit time ] > > > A third option is a different type of xattr operation that doesn't go to > > disk until the metadata updates done at IO end time. > > > > >From a performance point of view, it'll be much faster than slowing down > > commit with data writes. > > > > Can that work for you? > > I suspect not, since multiple files are involved. It's usually something > like > > write A > setxattr A > write B > setxattr C > > and all need to be committed atomically. The model really is a bundle of > arbitrary operations that commit atomically. > > Slower commit times aren't as much of a concern because this is on the > storage backend, behind client caches and so forth. I think it's > a reasonable price to pay for the stronger consistency. > > Hopefully it's not throwing too big a wrench into the data=ordered > machinery? It sort of looks like this is already what you get when taking > a snapshot (I see the call to wait_ordered_extnets in commit_transaction > when snaps_pending). If we make it optional, its fine by me to added a data=ordered flush at commit time. -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
