xfs
[Top] [All Lists]

Re: [PATCH] Add test 248: Check filesystem FITRIM implementation

To: karn@xxxxxxxx
Subject: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 21 Dec 2010 06:22:24 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <AANLkTi=2J5fi1uQazbzsEQ+658DhoqRaxHuMPN9JPVqW@xxxxxxxxxxxxxx>
References: <1291996407-26251-1-git-send-email-lczerner@xxxxxxxxxx> <20101220174146.GA32680@xxxxxxxxxxxxx> <alpine.LFD.2.00.1012211132450.6010@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=2J5fi1uQazbzsEQ+658DhoqRaxHuMPN9JPVqW@xxxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, Dec 21, 2010 at 03:03:03AM -0800, Phil Karn wrote:
> What is the plan for TRIM support in XFS? I don't see any mention in the
> 2.6.36.2 sources, so I guess the code you guys have been discussing must not
> be considered stable yet.
>
> How will it eventually work? Will the filesystem automatically issue the
> commands to the drive whenever a file is deleted, or will it always require
> some sort of prodding from a userspace program?


I submitted a patch to add FITRIM support, which should go into 2.6.38
if I get a positive review.  That is the variant that is triggered by
the fstim userspace program and what the test we're discussing here
exercises.  I've also prototyped various forms of online discard, but
none of them is quite ready yet.  I've started porting some allocator
patches from Dave forward, which are a requirement for reliable online
discard.  After that I need to decide which of the variants we'll
actually use. So far the "dumb" discard at transaction commit time shows
the best results.

> And what kind of experiences are people having with XFS on current SSDs? I
> just put an Intel drive in my newly upgraded box and I'm wondering if this
> blazing performance will screech to a halt when my cumulative writes exceed
> its 120 GB capacity. Does anyone have a standalone "drive optimizer" that
> understands XFS, i.e, that can examine an unmounted file system and issue
> the appropriate TRIM commands for every block on the free list?

The intel SSDs do quite fine without constant trimming, as do most
current SSDs.  I only know of one sample that areally needs periodic
trims, but AFAIK it's not generally available yet (sorry, can't name the
vendor due to NDAs).  But even with the current ones a TRIM once in a
while is useful, but about once every couple of weeks is enough.  For a
system not constantly loaded you can use Mark Lord's wiper.sh script,
but be aware it only works on disks / partitions and not on LVM volumes.
Once the FITRIM support is in you can use that for the same purpose,
with the benefit of also working over LVM, and also working nicely on
a system under heavy use, as it doesn't have to allocate all free space
as the userspace hack done by wiper.sh does.

> Or is the Intel drive somehow really good at avoiding write amplification
> even without TRIM help from the file system? I've heard that may be the
> case, but I don't understand how that can be.

No, the Intel disks actually degrade a lot after heavy use.
Unfortunately even regular trims don't always seem to solve this.

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