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. Sent from my iPad On May 27, 2012, at 9:15 AM, Krzysztof Adamski <k@xxxxxxxxxxx> wrote: > On Sun, 2012-05-27 at 09:34 +0200, Stefan Ring wrote: >>>> [root@siFlash test]# xfs_bmap -vp 2.r.96.0 >>>> xfs_bmap: xfsctl(XFS_IOC_GETBMAPX) iflags=0x4 ["2.r.96.0"]: Cannot allocate memory >>> >>> Try filefrag -v maybe, if your e2fsprogs is new enough. >>> >>> Trying to remember, ENOMEM in bmap rings a bell... but this is possibly indicative of an extremely fragmented file. >> >> True, I've had it happen with extremely fragmented files. >> >> I've started playing around with discard myself only recently, but so >> far I like the approach of using fstrim a lot better than the discard >> option: http://xfs.org/index.php/FITRIM/discard > > Check what blockdev --getra <md device> is set to. I used to have a > several second deletes on large (4GB) fragmented files when ra was the > default 256. Once I changed it to 4096 (best value will depend on your > setup) the deletes became instant. > > K > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
