Re: very slow file deletion on an SSD

On 5/26/12 9:40 PM, Eric Sandeen wrote:

On 5/26/12 8:49 PM, Joe Landman wrote:

quoted

On 05/26/2012 08:07 PM, Dave Chinner wrote:

quoted

On Sat, May 26, 2012 at 07:25:55PM -0400, Joe Landman wrote:

quoted

[root@siFlash test]# ls -alF  | wc -l
59
[root@siFlash test]# /usr/bin/time rm -f *
^C0.00user 8.46system 0:09.55elapsed 88%CPU (0avgtext+0avgdata
2384maxresident)k
25352inputs+0outputs (0major+179minor)pagefaults 0swaps

It's burning an awful lot of CPU time during this remove.

quoted

[root@siFlash test]# ls -alF  | wc -l
48

So, 48 files were removed, it was basically CPU bound and one took
2.6 seconds.

So, how big are the files, and does the one that took 2.6s have tens
of thousands of extents ('xfs_bmap -vp *' will dump the extent maps
for all the files)?

Getting some sort of out of memory error with bmap

[root@siFlash test]# ls -alF
total 50466476
drwxr-xr-x 2 root root       4096 May 26 21:40 ./
drwxr-xr-x 3 root root         17 May 26 19:32 ../
-rw------- 1 root root 1073741824 May 26 19:36 2.r.49.0

...

<snip>

quoted

[root@siFlash test]# ls -alF > x

[root@siFlash test]# xfs_bmap -vp x
x:
 EXT: FILE-OFFSET      BLOCK-RANGE          AG AG-OFFSET          TOTAL FLAGS
   0: [0..7]:          212681896..212681903  2 (7555752..7555759)     8 01111

[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.

Ah.

f074211f xfs: fallback to vmalloc for large buffers in xfs_getbmap

fixed it in 3.4

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs