From owner-freebsd-questions@freebsd.org Mon Aug 24 15:28:48 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A5BF3C4560 for ; Mon, 24 Aug 2020 15:28:48 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from bede.qeng-ho.org (bede.qeng-ho.org [217.155.128.241]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BZwy74vxDz3VRw for ; Mon, 24 Aug 2020 15:28:47 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (arthur.home.qeng-ho.org [172.23.1.2]) by bede.qeng-ho.org (Postfix) with ESMTP id 3A68A10678; Mon, 24 Aug 2020 16:28:40 +0100 (BST) Subject: Re: Suggestion regarding fsck output enhancement To: Polytropon , FreeBSD Questions References: <20200824104017.4c241ec0.freebsd@edvax.de> From: Arthur Chance Message-ID: <77485d5e-7ca0-219d-234c-0aab7e58af96@qeng-ho.org> Date: Mon, 24 Aug 2020 16:28:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200824104017.4c241ec0.freebsd@edvax.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BZwy74vxDz3VRw X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd@qeng-ho.org designates 217.155.128.241 as permitted sender) smtp.mailfrom=freebsd@qeng-ho.org X-Spamd-Result: default: False [-1.12 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.155.128.240/29]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[qeng-ho.org]; NEURAL_HAM_MEDIUM(-0.75)[-0.747]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.07)[-0.070]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13037, ipnet:217.155.0.0/16, country:GB]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-questions] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2020 15:28:48 -0000 On 24/08/2020 09:40, Polytropon wrote: > Today I came across a situation where I would think fsck should > output a little more information, which would be helpful especially > in diagnostics and dry-run sessions prior to recovery. > > Example: > > INCORRECT BLOCK COUNT I=24236 (288 should be 268) > CORRECT? yes > > Or: > > UNREF FILE I=63518082 OWNER=test1 MODE=100644 > SIZE=0 MTIME=Aug 24 09:45 2020 > RECONNECT? yes > > In both entries, the inode number is mentioned. Wouldn't it be > nice to display a file or directory name, if possible, to show > what file could be affected? Basically, it's what you can already > manually do: > > 1. run fsck in dry mode > (only list actions, do not take them) > > 2. note inode numbers > > 3. use fsdb to find out what the inodes point to > > 4. take specific action prior to fsck if needed > > My suggestion would be: If this kind of information is available, > fsck should display it, for example: > > INCORRECT BLOCK COUNT I=24236 (288 should be 268) > FILENAME ada0p4:/tmp/test.dat > CORRECT? yes > > Or: > > UNREF FILE I=63518082 OWNER=test1 MODE=100644 > FILENAME ada0p5:/home/test1/project/data/listing.ps > SIZE=0 MTIME=Aug 24 09:45 2020 > RECONNECT? yes > > Let's assume those messages would have been ansered "NO" > during a fsck dry run. > > The advantage: > > While fsck could zero out or truncate a file during repair, > it might be important for the operator to first try to mount > the partition r/o, copy the file out, unmount the partition, > have fsck repair the filesystem, and then replace the damaged > file from the previously obtained copy. This of course assumes > that the file in question can still be read, but would be > subject to "deleting" upon filesystem consistency restoration, > so it will not always be possible. > > Whom should I direct such a suggestion to? > > Or am I missing something that already exists? :-) Surely if an inode is unreferenced, by definition it does not have an entry in any directory, so has no name. Remember that files don't have names per se, directories are name to inode maps. Conversely a file which is hard linked multiple times will have many path names. Think /rescue which has 145 entries pointing at the same inode. However, for the usual case of singly linked files this could be very useful. I suspect it would slow down proceedings though, so should only be done for interactive uses of fsck -- The number of people predicting the demise of Moore's Law doubles every 18 months.