From owner-freebsd-hackers@freebsd.org Tue Dec 8 19:19:15 2015 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFCD59D4B53 for ; Tue, 8 Dec 2015 19:19:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D4B11298 for ; Tue, 8 Dec 2015 19:19:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by obbww6 with SMTP id ww6so19754221obb.0 for ; Tue, 08 Dec 2015 11:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=u6mUIa1S6P2XdrzxAlheaazRidNDBqR2RqSPJzZ2d8M=; b=0x5O/OBLyxLXtGFGur0mUlK11Jg/fNIhupKqXrNRPrmpr88ZSeubOAHY9x4R0a9K0n +G2owNopR7UVviENb/XfQuT191rO/chJelabHhDwP6IT/7JM9Y2Z1jcmI+gbqkPAWpQx 3JrCL48l2wNaDlQYRjod8GGuSihjZ1nay2LHn3oSjAWmfqStAvz8+ytAHjygTlf1NtFo IcPSH2PwvSm1wZNTtit/cZGu8dkOAI6s3C303Js3HBAvdkX/VFc88daL7hms40J6I4ws ZOT5gCyOHFfVMFYWcwPlc6rBhvY7vYvokF2Hh6d4sLOBuIqmf9L9ew6ozWQ12uoTWj+1 yqlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=u6mUIa1S6P2XdrzxAlheaazRidNDBqR2RqSPJzZ2d8M=; b=cOzbhiwm6KbcJ7FyOGmJ6WQXLPmp0JVRc7iucHn/iLvyhYdfsQ67cggARLoeMlMv5W Ts1Bh9LakATQamBfOIXCdKWXVkANrBQJipepB82mAtTvKqBve4c9zTZmtrifHWeNmVMx lRULQ0AvCmva+8c2+OLGkcaVupZ65PGI/9je6tHdnc7HESacyV6bkWIxBNN9KAsq8/Tz MeQBOC5jtZSQ+77bhpNrXC5V54AK7Goozv85RfUl5Ku19bBBROgWGgjEWu+ahwGHmhoN i9nIuJ4Pe5ef+EBRnzgQ0XkiM7wf28BlXQXBfmtm0REHnE1GzL+Fk+hSxMNwesNqAoYj OFsQ== X-Gm-Message-State: ALoCoQlhaeUK8zy+zfcScqMiNplv7nPPzY7zoE2ZvyQ2I+4o8AYfDBOi2fREFHmR92tBXEDRSKC2W8E+NqU5qRFQYd78eXsDcA== X-Received: by 10.60.67.104 with SMTP id m8mr1039364oet.37.1449602354648; Tue, 08 Dec 2015 11:19:14 -0800 (PST) Received: from ?IPv6:2601:280:4900:3700:4d3f:8eba:ea86:7700? ([2601:280:4900:3700:4d3f:8eba:ea86:7700]) by smtp.gmail.com with ESMTPSA id x131sm1896904oix.27.2015.12.08.11.19.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Dec 2015 11:19:13 -0800 (PST) Sender: Warner Losh Subject: Re: DELETE support in the VOP_STRATEGY(9)? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BC57BC0A-AA3E-464E-BE53-94B0B1DD300A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <20151208190622.GE82577@kib.kiev.ua> Date: Tue, 8 Dec 2015 12:19:11 -0700 Cc: Dag-Erling Sm??rgrav , "freebsd-hackers@freebsd.org" Message-Id: <0A599E1F-FF63-4F21-B765-44A4531968DB@bsdimp.com> References: <86poyhqsdh.fsf@desk.des.no> <86fuzdqjwn.fsf@desk.des.no> <864mfssxgt.fsf@desk.des.no> <86wpsord9l.fsf@desk.des.no> <20151208185818.GD82577@kib.kiev.ua> <20151208190622.GE82577@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 19:19:16 -0000 --Apple-Mail=_BC57BC0A-AA3E-464E-BE53-94B0B1DD300A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 8, 2015, at 12:06 PM, Konstantin Belousov = wrote: >=20 > 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 writes: >>>> Dag-Erling Sm??rgrav 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. >>>=20 >>> 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. Since the BIO_DELETE queue up in the storage layer, and we make no = requirement on ordering[*] in the storage layer, this is prudent. A BIO_WRITE could = overtake the BIO_DELETE, which would be bad. Warner [*] Well, apart from BIO_ORDERED which isn=E2=80=99t used for BIO_DELETE = requests and generally is only needed in FreeBSD to ensure that writes are = flushed out (with BIO_FLUSH) in a particular order for power-fail recovery. --Apple-Mail=_BC57BC0A-AA3E-464E-BE53-94B0B1DD300A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWZy0wAAoJEGwc0Sh9sBEAbJEQAIC1gd3LTznddZhgW+zwheyV JPaStJjcQCHUSb3DRzs+s+r7nMqMmUCSzqTUZEIwVEet8MT3lhUt8vQ+V7eC8EjF pGihuaVXPfqSMBZA9wl4OG1R4szXbNVNtz56ZmZpWXLnLdTwoVdR0Qbbqg5KbtXm cRdYRyAfEP8RJ7FeTB8rmYjsAFrm93R9oqI5415j8jX/eIOUjpsZJOVKmJzNSAMZ DtYMTUtMrx/UHi97PEnh4DhUs8O2D/jGjIke3khQtsLc4oluizMlkuxSq+fOH7sc NOS1pHwSFrj8OK6hh5MrLytHqXYecnouKMSWylyTp0gPsA0QZ+4ua5uJYh0oyWqo w1RjUqTUQQxGQeK61F7/s1cTn2GgR2GyNIWB/XTdn8rUbDZU8439j742Vz7jc8XQ +kQD6SA2H/+7WM0VjvZ/E0EPSIYAu5r4MhwE7xd38HOsfTukBiLUGCELPdqyAlqI rWEQAt7Jbfndi7w6z6lnbIEg7t1tifmXRVgWVMmHBf3hMJD28LdmGBdLYRjACy+e +qg+entLA9sLK2PCv4wZOqCsTiSfM7dLIW+6i4Urau9yfoLhFBpH0d7AcXZTug/D mWxcbW/6DSqBWBXtedpGPnSi5/vv4MD47p9bf3zq1a0s5dALfmm4bgg8/Y/kUreY qlXgGo12PmihfIoLgYNt =qcyS -----END PGP SIGNATURE----- --Apple-Mail=_BC57BC0A-AA3E-464E-BE53-94B0B1DD300A--