[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1241377472.5596.88.camel@mulgrave.int.hansenpartnership.com>
Date: Sun, 03 May 2009 14:04:32 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jeff Garzik <jeff@...zik.org>
Cc: Matthew Wilcox <matthew@....cx>,
Jens Axboe <jens.axboe@...cle.com>,
Boaz Harrosh <bharrosh@...asas.com>,
Hugh Dickins <hugh@...itas.com>,
Matthew Wilcox <willy@...ux.intel.com>,
linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-scsi@...r.kernel.org,
Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
Mark Lord <lkml@....ca>
Subject: Re: New TRIM/UNMAP tree published (2009-05-02)
On Sun, 2009-05-03 at 14:40 -0400, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > (2) determine at init if queue (a) supports explicit DISCARD and/or (b)
> > supports DISCARD flag passed with READ or WRITE
>
>
> As an aside -- does any existing command set support case #b, above?
Not to my knowledge.
I think discard was modelled on barrier (which can be associated with
data or stand on its own).
> AFAICT, ATA, SCSI and NVMHCI all have a single, explicit hardware
> command to discard/deallocate unused sectors.
>
> Therefore, creating REQ_TYPE_DISCARD seems to eliminate any need for new
> hook ->prepare_discard().
Well, yes and no ... in the SCSI implementation of either UNMAP or WRITE
SAME, we still need a data buffer to store either the extents or the
actual same data.
> This provides a 1:1 correspondence between hardware and struct request,
> most closely matching the setup of known hardware.
Agreed ... but we still have to allocate the adjunct buffer
somewhere ....
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists