xfs
[Top] [All Lists]

Re: automatically running fstrim

To: Phil Karn <karn@xxxxxxxx>
Subject: Re: automatically running fstrim
From: Lukas Czerner <lczerner@xxxxxxxxxx>
Date: Thu, 26 May 2011 09:56:18 +0200 (CEST)
Cc: Lukas Czerner <lczerner@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4DDD845E.9090709@xxxxxxxx>
References: <4DDBE293.8030203@xxxxxxxxxxxx> <alpine.LFD.2.00.1105251155120.4667@xxxxxxxxxxxxxxxxxxxxxxxxxx> <BANLkTi=8CX_rjWHFEjt5JO5oScdKoZopww@xxxxxxxxxxxxxx> <alpine.LFD.2.00.1105251335280.4667@xxxxxxxxxxxxxxxxxxxxxxxxxx> <4DDD845E.9090709@xxxxxxxx>
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
On Wed, 25 May 2011, Phil Karn wrote:

> On 5/25/11 4:47 AM, Lukas Czerner wrote:
> 
> 
> > unlinked often). Unfortunately xfs does not have this support yet, but
> > other filesystems do (ext4,btrfs,...) so if you like you might try one
> > of those and mount it with -o discard mount option. What it does is,
> > that it will send a TRIM for every range of freed filesystem blocks.
> > 
> > Generally, in its current state it comes with quite big performance
> > loss (that's why we have fstrim), but in you case it might be actually
> > more convenient than running fstrim all the time. Also it is handled
> > automatically and the only think needed is to pass the "-i discard"
> > mount option.
> 
> I have thought of using ext4 with the discard option on that device for
> just this reason. But this OCZ Revo SSD seems to execute TRIM rather
> slowly. I just timed it at 7 minutes 38 seconds to trim 46 GB of free
> space on a 90 GB SSD. I wouldn't want that to occur in the foreground
> while I'm running a program that's generating a lot of garbage blocks.
> 
> Intel drives, at least, seem to execute TRIM much faster; I think they
> can take more blocks in each operation, and I conjecture that the drive
> controller simply adds them to a "to do" list for later erasure in the
> background. So there should probably be an option for "real-time" TRIM
> on those SSDs that can do it without a performance penalty.

Well, this is a bit tricky. I have had a chance to test drive like this
and I realized that the drive seems to perform slower after more and
more trims sent to it. It did eventually recover, however it took about
half a minute to get performance back. Well, it is still a bit young
technology.

If you want to see some of my results, look here:
http://people.redhat.com/lczerner/discard/

there is also a tool available to do the testing.

> 
> It would be nice if the fitrim ioctl were to issue TRIM commands only
> for newly created garbage blocks that haven't already been trimmed. But
> I guess that would require some major changes to the file system data
> structures. At the least, it would require some special record-keeping
> to keep track of this information.

There are some patches for ext4 to do something like this, however it is
still not finished.

> The Intel drive shows it's possible
> to implement a very speedy TRIM, so maybe it won't be such a bad thing
> to just trim the whole free list every time.
> 
> Phil

Thanks!
-Lukas

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