Description of problem: Running xfs_fsr on highly active xfs volumes helps keep performance high. It might be helpful to have systemd units/timers for this. Version-Release number of selected component (if applicable):xfsprogs-3.2.0-0.3.alpha2.fc21 How reproducible:100% Steps to Reproduce: 1.do a bunch of random io fragementing an xfs volume 2.performance degrades 3. Actual results: unless you know to run xfs_fsr, performance degrades. Expected results: this could be run automatically Additional info:
Created attachment 857893 [details] xfs_fsr.service
Created attachment 857894 [details] xfs_fsr.timer
(In reply to Pat Riehecky from comment #0) > Description of problem: > Running xfs_fsr on highly active xfs volumes helps keep performance high. No, it doesn't. ;) xfs_fsr has no notion of freespace, and running it periodically over the whole filesystem can lead to severe freespace fragmentation, which in turns leads to fragmentation of newly allocated files. From the SGI CXFS admin guide (CXFS uses XFS as the filesystem): "Defragment Filesystems with Care The xfs_fsr tool is useful when defragmenting specific files but not filesystems in general. Using xfs_fsr to defragment CXFS filesystems is not recommended except on read-mostly filesystems because xfs_fsr badly fragments the free space. XFS actually does best at maintaining contiguous free space and keeping files from being fragmented if xfs_fsr is not run as long as there is a moderate amount (10% or more) of free space available on the filesystem"
I should probably ask, though - what workload are you running which causes such bad fragmentation? And what actual performance numbers do you have? It'd be interseting to run the xfs_db "freesp" command, and see what your available free space looks like at this point. -Eric
I'll have to get back to you on the output of xfs_db -c freesp. The filesystem is mounted right now. As for the workload, that is easier. Basically I've got a bunch of various scripts that find authorized linux iso torrents (Fedora and spins, Gentoo, Arch, Scientific Linux, Debian, Ubuntu, and so on). I pull down the torrent and seed it for more or less ever. I've got the disk space and bandwidth at home, so why not share. For years I'd been noticing the system get slower and slower. I finally decided to care enough and discovered the fragmentation report had me at 99.9% fragemented. After about 72h of xfs_fsr running (set the timer super high and at jobs to start it off again), my IO throughput went from about 7.8MB to 62.8MB. I measured with 'dd'. Thus the bug report
Ah, torrents can badly fragment a filesystem. Does your torrent client preallocate space first? If not, I'd find one that does (or configure yours to do so) and your problems should go away, assuming that you have some contiguous free space left. Always better to avoid fragmentation up front than to fix it later... As for the "fragmentation factor" see also: http://xfs.org/index.php/XFS_FAQ#Q:_The_xfs_db_.22frag.22_command_says_I.27m_over_50.25._Is_that_bad.3F 99.9% probably does indicate a problem, though, that's around 1000 extents per file. I'd look into teaching your torrent client to do a better job. What are you using? -Eric
I just checked the 'preallocate first' option in transmission :) Thanks for the help!
Hopefully transmission is "doing it right" by now ;)