xfs
[Top] [All Lists]

Re: [PATCH, RFC] xfs: batched discard support

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH, RFC] xfs: batched discard support
From: Mark Lord <liml@xxxxxx>
Date: Sun, 16 Aug 2009 10:26:03 -0400
Cc: xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, jens.axboe@xxxxxxxxxx, IDE/ATA development list <linux-ide@xxxxxxxxxxxxxxx>
In-reply-to: <20090816142331.GA4284@xxxxxxxxxxxxx>
Organization: Real-Time Remedies Inc.
References: <20090816004705.GA7347@xxxxxxxxxxxxx> <4A876255.10606@xxxxxx> <4A876CA9.20906@xxxxxx> <20090816022500.GA12392@xxxxxxxxxxxxx> <4A8802F3.6010908@xxxxxx> <4A8810C4.3050800@xxxxxx> <20090816142331.GA4284@xxxxxxxxxxxxx>
User-agent: Thunderbird 2.0.0.22 (X11/20090608)
Christoph Hellwig wrote:
On Sun, Aug 16, 2009 at 09:59:32AM -0400, Mark Lord wrote:
Okay, I got Matthews patches updated onto 2.6.31, and fixed the 
incompatibilities
between those and the XFS TRIM patch (from Christoph), plus a sector_t printk 
issue.

My apologies for attachments, but I am attaching the updated Christoph patch,
as well as my hacked-up forward-port of Matthew's patches.

Not pretty, but they work.  :)

Now.. running Christoph's "xfs trim" on a 4.6GB mostly already-trimmed
XFS partition gave this for the first time around:

The problem is, it still issues TRIMs to the LLD one extent at a time.
Compare this with doing it all in a single TRIM command
with the wiper.sh script (filesystem unmounted):

I could do a variant which issues a single TRIM, but that would require
us to lock out all other allocations for the time the trim takes.  I'll
hack that up once I get some time.
..

Matthew's stuff will have to change to support that, too.

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