Date: Tue, 8 Dec 2015 21:06:22 +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: <20151208190622.GE82577@kib.kiev.ua> In-Reply-To: <20151208185818.GD82577@kib.kiev.ua> References: <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
On Tue, Dec 08, 2015 at 08:58:18PM +0200, Konstantin Belousov wrote: > 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. I am sorry for the followup mail, but I probably have to explain more. The freed block, for which BIO_DELETE is issued, is not marked as free in the bitmap, until the BIO_DELETE completion is reported. In other words, we do not reuse the freed block while TRIM command is possibly executed.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151208190622.GE82577>