[Top] [All Lists]

Re: very slow file deletion on an SSD

To: joe.landman@xxxxxxxxx
Subject: Re: very slow file deletion on an SSD
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sun, 27 May 2012 11:07:02 -0500
Cc: Krzysztof Adamski <k@xxxxxxxxxxx>, Stefan Ring <stefanrin@xxxxxxxxx>, linux-raid <linux-raid@xxxxxxxxxxxxxxx>, "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
In-reply-to: <5856C5F0-C13E-415D-907B-491C1BBCC0C2@xxxxxxxxx>
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> <1338124504.28212.255.camel@xxxxxxxxxxxxxxxxxx> <5856C5F0-C13E-415D-907B-491C1BBCC0C2@xxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
On 5/27/12 9:59 AM, joe.landman@xxxxxxxxx wrote:
> 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?


<Prev in Thread] Current Thread [Next in Thread>