On Fri, Apr 28, 2017 at 11:53 AM, Peter Grandi <p...@btrfs.list.sabi.co.uk> wrote:
> 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. You can see from the examples I posted that these extents are all over the place, they're not contiguous at all. 4K here, 4K there, 4K over there, back to 4K here next to this one, 4K over there...12K over there, 500K unwritten, 4K over there. This seems not so consequential on SSD, at least if it impacts performance it's not so bad I care. On a hard drive, it's totally noticeable. And that's why journald went with chattr +C by default a few versions ago when on Btrfs. And it does help *if* the partent is never snapshot, which on a snapshotting file system can't really be guaranteed. Inadvertent snapshotting could be inhibited by putting the journals in their own subvolume though. Anyway, it's difficult to consider Btrfs a general purpose file system if other general purpose workloads like journal files, are causing a problem like wandering tree. Hence the subject of what to do about it, and that may mean short term and long term. I can't speak for systemd developers but if there's a different way to write to the journals that'd be better for Btrfs and no worse for ext4 and XFS, it might be considered. -- Chris Murphy -- 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
