Date: Tue, 08 Dec 2015 20:20:39 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-hackers\@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Fwd: DELETE support in the VOP_STRATEGY(9)? Message-ID: <86h9jsrblk.fsf@desk.des.no> In-Reply-To: <20151208185818.GD82577@kib.kiev.ua> (Konstantin Belousov's message of "Tue, 8 Dec 2015 20:58:18 %2B0200") 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> <20151208185818.GD82577@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov <kostikbel@gmail.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). > 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. 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?86h9jsrblk.fsf>