Date: Tue, 8 Dec 2015 20:58:18 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Dag-Erling Sm??rgrav <des@des.no> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)? Message-ID: <20151208185818.GD82577@kib.kiev.ua> In-Reply-To: <86wpsord9l.fsf@desk.des.no> References: <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 Tue, Dec 08, 2015 at 07:44:38PM +0100, 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). I again agree. This is how UFS issues TRIM. When the data block is freed and there are no dandling pointers in the inode copy on disk pointing to the block, BIO_DELETE is issued if volume reports it. Everything else is up to the geom stack and driver. > > Anyway, my point is that Maxim needs to revise his assumptions. Which does not invalidate the fact that a 'punch hole' interface is useful.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151208185818.GD82577>