> [ ... ] And that makes me wonder whether metadata > fragmentation is happening as a result. But in any case, > there's a lot of metadata being written for each journal > update compared to what's being added to the journal file. [ > ... ]
That's the "wandering trees" problem in COW filesystems, and manifestations of it in Btrfs have also been reported before. If there is a workload that triggers a lot of "wandering trees" updates, then a filesystem that has "wandering trees" perhaps should not be used :-). > [ ... ] worse, a single file with 20000 fragments; or 40000 > separate journal files? *shrug* [ ... ] Well, depends, but probably the single file: it is more likely that the 20,000 fragments will actually be contiguous, and that there will be less metadata IO than for 40,000 separate journal files. The deeper "strategic" issue is that storage systems and filesystems in particular have very anisotropic performance envelopes, and mismatches between the envelopes of application and filesystem can be very expensive: http://www.sabi.co.uk/blog/15-two.html?151023#151023 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
