| To: | Stefan Ring <stefanrin@xxxxxxxxx> |
|---|---|
| Subject: | Re: very slow file deletion on an SSD |
| From: | Krzysztof Adamski <k@xxxxxxxxxxx> |
| Date: | Sun, 27 May 2012 09:15:04 -0400 |
| Cc: | Eric Sandeen <sandeen@xxxxxxxxxxx>, Joe Landman <joe.landman@xxxxxxxxx>, linux-raid <linux-raid@xxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx |
| In-reply-to: | <CAAxjCEzX4dmm6YuR__1_a6mw+D=vizV0VrCLqCC-d5GSgkbE6g@xxxxxxxxxxxxxx> |
| References: | <4FBF60D1.80104@xxxxxxxxx> <20120526231838.GR25351@dastard> <4FC16683.9060800@xxxxxxxxx> <20120527000701.GS25351@dastard> <4FC18845.6030301@xxxxxxxxx> <4FC19408.5020502@xxxxxxxxxxx> <CAAxjCEzX4dmm6YuR__1_a6mw+D=vizV0VrCLqCC-d5GSgkbE6g@xxxxxxxxxxxxxx> |
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 |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Vahvista Identity Webmail, Webmail ylläpitäjä |
|---|---|
| Next by Date: | Re: very slow file deletion on an SSD, joe . landman |
| Previous by Thread: | Re: very slow file deletion on an SSD, Stefan Ring |
| Next by Thread: | Re: very slow file deletion on an SSD, joe . landman |
| Indexes: | [Date] [Thread] [Top] [All Lists] |