Re: very slow file deletion on an SSD
flat view
From: Joe Landman <hidden>
Date: 2012-05-27 17:17:05
Also in:
linux-xfs
On 05/27/2012 12:07 PM, Eric Sandeen wrote:
On 5/27/12 9:59 AM, joe.landman@gmail.com wrote:quoted
This is going to be a very fragmented file. I am guessing that this is the reason for the long duration delete. I'll do some more measurements before going to 3.4.x as per Eric's note.filefrag -v should also tell you how many fragments, and because it uses fiemap it probably won't run into the same problems. But it sounds like we can just assume very high fragmentation. It's not addressing the exact issue, but why are the files so fragmented? Are they very hole-y or is it just an issue with how they are written? Perhaps preallocation would help you here?
... and one pass with xfs_fsr seems to have "fixed" the problem [root@siFlash test]# xfs_fsr xfs_fsr -m /proc/mounts -t 7200 -f /var/tmp/.fsrlast_xfs ... /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 /data/1 start inode=0 /data/2 start inode=0 /data/3 start inode=0 Completed all 10 passes [root@siFlash test]# filefrag 1.r.48.0 1.r.48.0: 1 extent found [root@siFlash test]# rm -f 1.r.48.0 (very fast) -- Joseph Landman, Ph.D Founder and CEO Scalable Informatics Inc. email: landman@scalableinformatics.com web : http://scalableinformatics.com http://scalableinformatics.com/sicluster phone: +1 734 786 8423 x121 fax : +1 866 888 3112 cell : +1 734 612 4615