[ ... ] > Same again - aparently when you system goes idle, it burns a CPU in > user time, but stops doing that when IO is in progress. >> This time, I ran a sync. That should mean all of the discard >> operations were completed...right? > Well, it certainly is the case for XFS. I'm not sure what is > happening with ext4 though. >> If it makes a difference, when I get the i/o hang during the >> xfs deletes, my entire system seems to hang. It doesn't just >> hang that particular mounted volumes' i/o. > Any errors in dmesg? I had hoped that the OP would take my suggestions and runs some web search, because I was obviously suggesting that there the behaviour he saw is expected and correct for XFS: >>> * Learn how TRIM is specified, and thus why many people prefer >>> running periodically 'fstrim' which uses FITRIM to mounting >>> with 'discard'. So let's cut it short: the TRIM command is specified to be synchronous. Therefore a sequence if TRIM operations will lock up the disk, and usually as a result the host too. In addition to this, in some implementations TRIM is faster and in some it is slower, but again the main problem is that it is synchronous. Therefore using 'discard' which uses TRIM is subject to exactly the behaviour reported. But 'ext4' batches TRIMs, issuing them out of the journal, while XFS probably issues them with every deletion operation, so 'ext4' should be hit less, but the difference should not be as large as reported. I suspect then that recent 'ext4' ignores 'discard' precisely because of the many reports of freezes they may have received. An early discussion of the issue with TRIM: http://www.spinics.net/lists/linux-fsdevel/msg23064.html >From this report it seems that 'ext4' used to be "slow" on 'discard' too: https://patrick-nagel.net/blog/archives/337 "I did it three times with and three times without the “discard” option, and then took the average of those three tries: Without “discard” option: Unpack: 1.21s Sync: 1.66s (= 172 MB/s) Delete: 0.47s Sync: 0.17s With “discard” option: Unpack: 1.18s Sync: 1.62s (= 176 MB/s) Delete: 0.48s Sync: 40.41s So, with “discard” on, deleting a big bunch of small files is 64 times slower on my SSD. For those ~40 seconds any I/O is really slow, so that’s pretty much the time when you get a fresh cup of coffee, or waste time watching the mass storage activity LED." Also the 'man' page for 'fstrim': http://www.vdmeulen.net/cgi-bin/man/man2html?fstrim+8 "-m, --minimum minimum-free-extent Minimum contiguous free range to discard, in bytes. (This value is internally rounded up to a multiple of the filesystem block size). Free ranges smaller than this will be ignored. By increasing this value, the fstrim operation will complete more quickly for filesystems with badly fragmented freespace, although not all blocks will be discarded. Default value is zero, discard every free block." Note the "By increasing this value, the fstrim operation will complete more quickly for filesystems with badly fragmented freespace", which implies that FITRIM is also synchronous or slow or both. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
