From owner-svn-src-all@freebsd.org Fri Nov 30 18:04:41 2018 Return-Path: Delivered-To: svn-src-all@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 31176114B533 for ; Fri, 30 Nov 2018 18:04:41 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 7ADB96EEF4 for ; Fri, 30 Nov 2018 18:04:40 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-ot1-f41.google.com with SMTP id k98so5913428otk.3 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=fKXe3pR3POEFLjVC4TDOwg6zOu/dEcPlA+uARcqCWCcat8Af9om9VEk9VjprBNfGel 5g573nayIlQYi85qOx8isQUm0Ndt8yu9lnB7hk9hEYulKL2IjOLgAul30HNENuM3SZTt O235CzTAhZrg3E/NeVAZfdU+Athv5Fm6sNdJ7Jn7D+F8EsngYhiR6pZWEe0POTJ5kR4V vztF0IbFogjEHBPxFnhg24Ywqd7hNqY44grcE+8O1qTEWzUCQXnlzCihwu5CzNQn5O60 rTKQ2mdwy9Y0PnHGJ99SUd2tqVlb1YCrPc7AWwzLKMLhELow28qcV2v01J71s6v7fXW+ bKDw== X-Gm-Message-State: AA+aEWZ5ieelYDGpRFkr6bB9qSkJCNYR7wfCCOMeFM5NunJspmeGWBgg o7EgSNknwQP0wxDKKvPGNDr+2o1LkDjJFmgB4v8Wjg== 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: 7ADB96EEF4 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-all@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; 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)[41.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-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" 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 > >