Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Dec 2015 20:29:04 +0100
From:      =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Steven Hartland <killing@multiplay.co.uk>,  freebsd-hackers@freebsd.org
Subject:   Re: DELETE support in the VOP_STRATEGY(9)?
Message-ID:  <86d1ugrb7j.fsf@desk.des.no>
In-Reply-To: <0DB97CBA-4DC3-4D52-AE9D-54546292D66F@bsdimp.com> (Warner Losh's message of "Tue, 8 Dec 2015 12:03:11 -0700")
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> <566726ED.2010709@multiplay.co.uk> <0DB97CBA-4DC3-4D52-AE9D-54546292D66F@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh <imp@bsdimp.com> writes:
> Dag-Erling Sm=C3=B8rgrav <des@des.no> writes:
> > 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).
> That ship has sailed. UFS, at least, assumes that if TRIM is supported
> then relocating files to be contiguous is bad.  But writing a gnop
> module that did the BIO_DELETE thing would be bogus.

No less bogus than any other implementation of BIO_DELETE.  I could
write a gnop-like module that silently discards them.  My point is that
it's wrong to infer anything else from GEOM::candelete support than the
fact that BIO_DELETE requests will be accepted and may or may not do
something, somewhere, at some point.  We can easily create a different
GEOM attribute which indicates that seeks are essentially free, and FFS
could use that instead of GEOM::candelete to disable relocation.

> BIO_DELETE does not mean that blocks will read back as zeros.

It doesn't mean they won't, either.

> So, sure you could invent a stupid thing that breaks the rules, and
> thus the assumptions of the other code, but why would you want to do
> that?

It wouldn't break any rules or valid assumptions.

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86d1ugrb7j.fsf>