On Mon, Nov 28, 2016 at 10:51:42AM +0100, Gionatan Danti wrote: > > > On 27/11/2016 23:14, Dave Chinner wrote: > > > >Ah, hard link farms. aka "How to fragment the AGI btrees for fun and > >profit." > > > > Interesting... there is anything I can read about AGI fragmentation? Read up on finobt and the bug reports on the list about how inode allocation slows to a crawl.... > >Nope, but it means that what should be sequential IO is probably > >going to be random. i.e. instead of directory/inode/extent reading > >IO having minimum track-track seek latency because they are all > >nearby (1-2ms), they'll be average seeks (6-7ms) because locality is no > >longer as the filesystem has optimised for. > > > > Should not thinp overhead be minimized by the big (8 MB) chunk size? Minimised - maybe. Removed - no. > Are inode allocation so much scattered around LBAs? Yes. XFS distributes inodes across the entire device LBA. > Maybe the > slowdown can be increased by bad journal placement (I imagine it is > near the start of the disk, while current read/write activity surely > happen near the end)? Contributing factor, yes. You just have to live with that thinp behaviour. > >noalign affects data placement only, and only for filesystems that > >have a stripe unit/width set, which yours doesn't: > > > >> sunit=0 swidth=0 blks > > Isn't that the proper results of "noalign"? No. "noalign" is a mount option - the sunit/swidth are geometry values stored in the superblock. noalign will override the superblock values, but it does not make them go away. > By opting for "noalign" > I am telling mkfs to discard any stripe information, right? No. You are telling it to ignore stripe alignment for file data allocation purposes. > >Yes. Made worse by being on a thinp volume. > > I can't do anything for that? Nope. There's always going to be a penalty for subverting the filesystem's physical layout optimisations on storage subsystems that require physical layout optimisation for performance. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
