| To: | Mark Lord <liml@xxxxxx> |
|---|---|
| Subject: | Re: [PATCH, RFC] xfs: batched discard support |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Sun, 16 Aug 2009 10:23:31 -0400 |
| Cc: | Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-scsi@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, jens.axboe@xxxxxxxxxx, IDE/ATA development list <linux-ide@xxxxxxxxxxxxxxx> |
| In-reply-to: | <4A8810C4.3050800@xxxxxx> |
| References: | <20090816004705.GA7347@xxxxxxxxxxxxx> <4A876255.10606@xxxxxx> <4A876CA9.20906@xxxxxx> <20090816022500.GA12392@xxxxxxxxxxxxx> <4A8802F3.6010908@xxxxxx> <4A8810C4.3050800@xxxxxx> |
| User-agent: | Mutt/1.5.19 (2009-01-05) |
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. |
| Previous by Date: | Re: [PATCH, RFC] xfs: batched discard support, Mark Lord |
|---|---|
| Next by Date: | Re: [PATCH 1/4] xfs: fix locking in xfs_iget_cache_hit, Eric Sandeen |
| Previous by Thread: | Re: [PATCH, RFC] xfs: batched discard support, Mark Lord |
| Next by Thread: | Re: [PATCH, RFC] xfs: batched discard support, Mark Lord |
| Indexes: | [Date] [Thread] [Top] [All Lists] |