Date: Tue, 8 Dec 2015 18:52:29 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-hackers@freebsd.org Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)? Message-ID: <566726ED.2010709@multiplay.co.uk> In-Reply-To: <86wpsord9l.fsf@desk.des.no> References: <CAH7qZftSVAYPmxNCQy=VVRj79AW7z9ade-0iogv2COfo2x%2Ba2Q@mail.gmail.com> <201512052002.tB5K2ZEA026540@chez.mckusick.com> <CAH7qZfs6ksE%2BQTMFFLYxY0PNE4hzn=D5skzQ91=gGK2xvndkfw@mail.gmail.com> <86poyhqsdh.fsf@desk.des.no> <CAH7qZftVj9m_yob=AbAQA7fh8yG-VLgM7H0skW3eX_S%2Bv75E-g@mail.gmail.com> <86fuzdqjwn.fsf@desk.des.no> <CANCZdfo=NfKy51%2B64-F_v%2BDh2wkrFYP4gXe=X9RWSSao49gO9g@mail.gmail.com> <CANCZdfqHoduhdCss0b6=UsBPAxfRZv4hF8vyuUVLBdP5gYUduQ@mail.gmail.com> <864mfssxgt.fsf@desk.des.no> <CANCZdfoXdcD%2B9jeVR1Np16gafBf0_4B2wombwxze8DvJwf7cMg@mail.gmail.com> <86wpsord9l.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/12/2015 18:44, Dag-Erling Smørgrav wrote:
> Warner Losh <imp@bsdimp.com> writes:
>> Dag-Erling Smørgrav <des@des.no> writes:
>>> But the filesystem does not know whether the underlying storage is
>>> electromechanical or solid-state, nor does it know whether the user
>>> cares much about seek times (unless we introduce the heuristic
>>> "avoid creating holes unless the file already has them, in which
>>> case the userland probably does not care").
>> Actually, the filesystem does know. Or has some knowledge of what
>> is supported and what isn't. BIO_DELETE support is a strong indicator
>> of a flash or other log-type system.
> The filesystem can ask the layer below if BIO_DELETE is supported, but
> should not assume anything about what it means. For instance, I could
> write a gnop-like module that translates BIO_DELETE into an all-zeroes
> BIO_WRITE and passes everything else unmodified. It would provide a
> stronger guarantee than, say, SATA TRIM but would also have a completely
> different performance profile (even on SSDs, since it would do its work
> synchronously whereas TRIM works asynchronously).
>
> Anyway, my point is that Maxim needs to revise his assumptions.
Just to clarify most consumer devices process TRIM synchronously, not
asynchronously.
Your example isn't actually just an example CAM scsi_da has a number of
different ways it can process BIO_DELETE:
* ATA TRIM
* SCSI UMAP
* Write Same 16
* Write Same 10
* Zero
So you example is actually exists in practice in the FreeBSD code base ;-)
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?566726ED.2010709>