Date: Tue, 8 Dec 2015 12:34:16 -0700 From: Warner Losh <imp@bsdimp.com> To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= <des@des.no> Cc: Steven Hartland <killing@multiplay.co.uk>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: DELETE support in the VOP_STRATEGY(9)? Message-ID: <CANCZdfrgkA-znp8jL%2BfDgkXwaTSBeNJVTXj6mDKQxdYtht3uzA@mail.gmail.com> In-Reply-To: <86d1ugrb7j.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> <566726ED.2010709@multiplay.co.uk> <0DB97CBA-4DC3-4D52-AE9D-54546292D66F@bsdimp.com> <86d1ugrb7j.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 8, 2015 at 12:29 PM, Dag-Erling Sm=C3=B8rgrav <des@des.no> wrot= e: > 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, bu= t > > > should not assume anything about what it means. For instance, I coul= d > > > write a gnop-like module that translates BIO_DELETE into an all-zeroe= s > > > 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 wo= rk > > > 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. When this was implemented, we thought about that. But we couldn't come up with any cases where you'd have one set and not the other. And the actual thing you'd want isn't that seeks are free, though that's a good clue. The actual thing you want is to know if there's a performance benefit to keeping files contiguous, and the extent size where that stops making sense. > > > 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. Actually, I'm wrong here. You are correct. I got carried away a bit. Sorry. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrgkA-znp8jL%2BfDgkXwaTSBeNJVTXj6mDKQxdYtht3uzA>