From owner-svn-src-head@freebsd.org Fri Nov 30 18:04:41 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D4E3114B531 for ; Fri, 30 Nov 2018 18:04:41 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D0446EEF5 for ; Fri, 30 Nov 2018 18:04:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ot1-f52.google.com with SMTP id u16so5892257otk.8 for ; Fri, 30 Nov 2018 10:04:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FxRRlnQRnSj2yy8XuM0kkbuiWRXYhZBw0yobjU4R+z0=; b=U/dseGQe801jDo85wvMD9lE0DeeGXf6XyDTODx3UsG45f+SIDyOLDjjjcb4XfmopS7 DvTmwObBlEIITfNa9g2CYTRaHevi4oriApYIuMQ7rknEPNiG17NI1I49ia2IJFOfqvr4 weXuvFlZopWyFc6jkGxIeB9xeKE+nUHd27fMnNjdh9Zeb/J5ss1h10N+Q0P0aInlo/MP gJu8if5RhG47PGPrO54KhwoH1X/Yzeo/fivySQfpU2/D/FUDOPFeRtXEsUH5VpB6JiXA DaOIqkTMDiz+S7iRYZ1t5bLcZW5RXGDWcftENrep7SVsYQ5x6LeV5SW+QZK32uO59AH9 y7aA== X-Gm-Message-State: AA+aEWZnM3vP49y5yFTomLibH5vasgvdAuQ4VDj3Sq/1/XV5ZWvsaDVw fuvc+k5bcdTx75qeYCkuIVpWoLzm69ksG+EapirDzg== X-Google-Smtp-Source: AFSGD/XbqDUH+21TEJ3fyDGrJwhfWoscyHmIg/tJVQ7jBbk1/Cdg6JipF4ItdCIuqP61AQ3d3F6c0Cx5ukKNvpLmBdo= X-Received: by 2002:a9d:6c5:: with SMTP id 63mr1602560otx.81.1543601073449; Fri, 30 Nov 2018 10:04:33 -0800 (PST) MIME-Version: 1.0 References: <201811301646.wAUGkICh019024@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201811301646.wAUGkICh019024@pdx.rh.CN85.dnsmgr.net> From: Maxim Sobolev Date: Fri, 30 Nov 2018 10:04:21 -0800 Message-ID: Subject: Re: svn: head/usr.bin: . trim To: rgrimes@freebsd.org Cc: Warner Losh , Alexey Dokuchaev , Eugene Grosbein , src-committers , svn-src-all@freebsd.org, steven.hartland@multiplay.co.uk, svn-src-head@freebsd.org, Cy Schubert X-Rspamd-Queue-Id: 7D0446EEF5 X-Spamd-Result: default: False [-3.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-head@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RWL_MAILSPIKE_GOOD(0.00)[52.210.85.209.rep.mailspike.net : 127.0.0.18]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_IN_DNSWL_NONE(0.00)[52.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-0.97)[ipnet: 209.85.128.0/17(-3.42), asn: 15169(-1.34), country: US(-0.09)]; FORGED_SENDER(0.30)[sobomax@freebsd.org,sobomax@sippysoft.com]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[sobomax@freebsd.org,sobomax@sippysoft.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2018 18:04:41 -0000 Well, I personally think "erase" better describes the option in question. "delete" is ambiguous, since nothing is really "deleted" here and "trim" refers to a name of a particular command in a particular protocol, which may or may not be around in 10 years from now. However, it looks like the industry has settled on that term for now and we've adopted utility with that very name, so I've updated my review request with that. https://reviews.freebsd.org/D18382 Other than that, it would work just as Warner has described. That all being said, I think it might need some other option to actually zero-out block before we trim them out. What I discovered is that unlike say our md(4), actual SATA hard drives may still return some, possibly random, data after BIO_DELETE'ing the corresponding block. So if you have say a big file filled with zeroes for whatever reason, then making a copy of your fs with conv=trim would likely result in some old garbage in that file after such an operation, unless you zero-out the content in advance. As an option, I could possibly make a modifications so that: "conv=sparse,trim" performs just a TRIM "conv=trim" performs write(NIL)+TRIM Then we can have a cake and eat it too. :) -Max On Fri, Nov 30, 2018 at 9:03 AM Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > On Fri, Nov 30, 2018 at 5:57 AM Alexey Dokuchaev > wrote: > > > > > On Fri, Nov 30, 2018 at 07:27:46PM +0700, Eugene Grosbein wrote: > > > > 30.11.2018 18:55, Alexey Dokuchaev wrote: > > > > > > > > >>> Another point: the manpage says, "It is only relevant for flash > based > > > > >>> storage devices that use wear-leveling algorithms", which is an > > > argument > > > > >>> against generic "trim". I would mind less of it would be called > > > ftrim(8) > > > > >>> or ssd_trim(8) or flash_trim(8), but still prefer Maxim's > approach. > > > > > > > > [skip] > > > > > > > > > Yes, I understand you. Like I've said, a little more > > > flash-media-related > > > > > name would perhaps be more appropriate for such an utility. > > > > > > > > This excludes virtio_blk and ZFS. Perhaps, manpage should be > corrected > > > > as quoted phrase has been taken from news -E description as is. > > > > > > How about mtrim(8) or media_trim(8)? I vaguely when back in times > misc/mc > > > was installed as bin/midc because some commercial Unix implementation > had > > > "mc" as a "media copy" command or something like that. > > > > > > > We should just put it in dd and remove this experiment. Both of these > > suggested names are horrible. They are too specific. And the notion that > > trim is too generic may have some merit, but the cure is worse than the > > disease. > > > > So I'm back to my point: we should just put it into dd and move on with > our > > lives. It's really the right place for it. > > > > Why? > > > > Because then we can have 'dd if=image of=/dev/foo conf=sparse,erase' and > it > > conf -> conv, and why erase? We are not actually erasing anything > during this "copy" operation. I am having some confusion as to > how the above would actually do the same thing that trim(8) implements. > > I do not really care if this is implemented as trim(8) or part of > dd, either way is reasonable, though I am upset at repeating the > discussion that already occured pre commit. Seems not enough > committers follow hackers any more, so that has become a poor > forum for vettting ideas, and now we post commit vet them on > -commit. > > > will erase the bits of the drive that are all 0's. We won't have to > resort > > to weird hacks to make most of them trimmed. While this works only on > media > > where trim is persistently 0's, that describes all modern flash media and > > most (all?) of the virtualization / thin storage scenarios I'm aware of. > > You can't do that with the current utility, at least not w/o a lot of > > effort. > > If your reading from file image and writting to dev foo I do > not see that description matching the above command invocation. > > I think it would be: > dd if=/dev/foo of=/dev/foo conv=noerror,sync,trim > sparse is not involved, it is for files, not devices. > erase imho is the wrong keyword, nothing in the trim/delete > world calls this operation erase do they? > trim could imply noerror,sync. > > -- > Rod Grimes > rgrimes@freebsd.org > >