Date: Tue, 8 Dec 2015 21:51:01 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Dag-Erling Sm??rgrav <des@des.no> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)? Message-ID: <20151208195101.GG82577@kib.kiev.ua> In-Reply-To: <86h9jsrblk.fsf@desk.des.no> References: <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> <20151208185818.GD82577@kib.kiev.ua> <86h9jsrblk.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 08, 2015 at 08:20:39PM +0100, Dag-Erling Sm??rgrav wrote: > Konstantin Belousov <kostikbel@gmail.com> writes: > > Dag-Erling Sm??rgrav <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). > > 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. > > I'm not sure what point you're trying to make. I get the impression > that you didn't really read what I wrote, just skimmed it and then > included it as decoration, and that you're making the same mistake I'm > trying (unsuccessfully, it seems) to prevent Maxim from making. Please > go back and read everything I've written before. Yes, it's long(ish), > but that's because it's a difficult problem which won't be solved by > pretending it's easy and ignoring everybody who tells you it isn't. > > > > Anyway, my point is that Maxim needs to revise his assumptions. > > Which does not invalidate the fact that a 'punch hole' interface is > > useful. > > Allow me to quote my first email on the subject: > > | I'm not opposed to the idea of VOP_DELETE or similar, but don't assume > | that "punching through" is always the correct semantic, and don't assume > | that it will be easy to implement - and it will have to be implemented > | correctly at every layer, in every geom, in every storage driver etc. > | There are many details to work out and many opportunities for mistakes. I wrote that VOP_DELETE() or any other interface should work at the level of data blocks consituing the file data, and its only action should be removing the blocks from the inode, same as is done unlink or truncate. I wrote that any BIO_DELETE bios issued by the filesystem, should be issued by the code which already acts on freeing the blocks. In other words, no new handling or new semantic for BIO_DELETE is required (at least in context of UFS). We already issue BIO_DELETE on UFS. If your argument about being hard or impossbile for VOP_DELETE() is valid, it must be valid for the current UFS code. But I do not see how.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151208195101.GG82577>