From owner-freebsd-questions@freebsd.org Mon Aug 24 15:48:20 2020 Return-Path: <owner-freebsd-questions@freebsd.org> 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 82EE53C4CC6 for <freebsd-questions@mailman.nyi.freebsd.org>; Mon, 24 Aug 2020 15:48:20 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BZxNf1zjDz3Wcd for <freebsd-questions@freebsd.org>; Mon, 24 Aug 2020 15:48:17 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.223.163.154]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.167]) with ESMTPA (Nemesis) id 1MUp8r-1k13de1pNB-00Qggg; Mon, 24 Aug 2020 17:48:15 +0200 Date: Mon, 24 Aug 2020 17:48:15 +0200 From: Polytropon <freebsd@edvax.de> To: Arthur Chance <freebsd@qeng-ho.org> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Suggestion regarding fsck output enhancement Message-Id: <20200824174815.7447f0d3.freebsd@edvax.de> In-Reply-To: <77485d5e-7ca0-219d-234c-0aab7e58af96@qeng-ho.org> References: <20200824104017.4c241ec0.freebsd@edvax.de> <77485d5e-7ca0-219d-234c-0aab7e58af96@qeng-ho.org> Reply-To: Polytropon <freebsd@edvax.de> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:JUp1iM4bGDv0cxCUlEefVT4Q6OlM1s4G2gnjmPsdd7vtSxnvLsF XBstfwZUN9Y8bPMZ7GDK9M7nTYFx+dR4Q58t1zeVpiukj7oogUi75fqjqeVbuegK/PNaM+J QKSGGokvr9sRYSvpJWPHY12Q+EmpeH7wH+lRwlASvEQDMXXxIyen6KxYxckho+bCDn4bt5F agxlk4TNXS96AX47QXuHg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:cGaXvL71PZM=:jRfiqIahzfBrEycdWQVNmU iJgnnfszTA3cBI3cYeAoHGCE2G9armp7eQBbtKbOI62rG9M7oK5jgUreldP/+uci3oOnPl4EZ iE8jxwIDGgE/oomuukNtDrdM7eZPdpeKSKx+aaAdpCsfXsvKTRFsyxdmZtFaTvNn7bpZM3xqt xqkdk3YW8KSAc7D6N7rIa0O+EK9u+tmE/Evr8nPWjvJzyp6SEV8zf7TwHzANaR9nysEQIR34P qR8hWVBpJCXBb6dYhvVHasr6Xiph1ZwfK+g+1QXaHWSI+LM/6gTz0/HOOuToAEf+1gRqW5i+p N8A0o5eRx6ul6pr7tGXVF8b4XSGXfA9AYig+Af/cNgV7XRFlhvfSh9sgh4EzamAjALJ4ByKJ4 RiDZ5Ck0hwUaP8CAr93fAnHlnfOqEVo8B4Lg3lXavrQk5TpuD8l/3vGPUGlc8w8/Vhf1WqC7N 2rQ0AuURCl2AVoj1g0/nwnM5QRQJCalW4GJxAO/AWfiwhaINDA5mep6pm+eh8cJJIBOSQC5Yr zq17KujCLQsCLydpZxVoEFgLju4N+MQdtZhGz1c/pUVITr097afUc1tlRiB0C7eKoUKJF3dX4 9krCIwJ7gw4Pf/Slj31R7K1/Rmtrk9uZTV5KbtmdZvVLxKiqIEgA29iplX291WQ4qkB1rripn oDUE1m4l3UAwhKRacw02uXF8xItG5Y8iYEDfdTQ8J2nWMXUup27mnjScKCgncgQIZA0YLMkbD TZhwapmswY7fg1yjWqwG5jxuKdonl44pPmJTZ45VyL3l4P4PcKNzdeIuI04fdTH2R+nszH8j5 1kNrLsZd86E9Jq0KPT99XKOzfeClKgAMyFKcGoUcKQP1ZDuglm1rsjDHNb7WPZxfEPEXiq6 X-Rspamd-Queue-Id: 4BZxNf1zjDz3Wcd X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.126.134) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [3.51 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[94.223.163.154:received]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.44)[0.440]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.67)[0.666]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.134:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.134:from]; 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 <freebsd-questions.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/> List-Post: <mailto:freebsd-questions@freebsd.org> List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>, <mailto:freebsd-questions-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 24 Aug 2020 15:48:20 -0000 On Mon, 24 Aug 2020 16:28:40 +0100, Arthur Chance wrote: > 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. Yes, that is corrent, and the reason I wrote "if possible", for example in messages things like incorrect block count. While unreferenced inodes will show up in the partition's /lost+found directory, with the inode number being their name (and usually having their original content), truncated inodes (or those _intended_ to be truncated or zeroed out) in certain cases have a name. This can be found out by using fsck in "dry run mode", and then checking the inodes mentioned using the fsdb program. > 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. True, and this generally applies to all hardlinked entries (multiple names assigned to the same file). > 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 Of course. There is no benefit in knowing that there once was a file /tmp/important.txt which has been truncated to size 0, so it's still there, while the important business data associated with that name isn't - it's still on the disk, but not referenced by an inode. In such a scenario, the interactive method would surely improve when you _know_ that a file would be truncated, so you could stop fsck at that time and at least try to use the "mount unclean partition r/o to get the file's content" approach. You could then have fsck restart and complete the repair, and from the previously saved copy, reconstruct the file if needed. As I mentioned, this is interesting in very rare cases where a sudden system crash corrupts the filesystem integrity in a way that a regular fsck run would make important data unaccessible (for example, an important business memo you're been writing). My suggestion is simply due to the fact that I had to deal with this very unpleasant kind of situation a few times, and being able to know what will be "gone" before it happens would really be an advantage. Oh, and the message should be in the "<tag>=<data>" format like all the other entries, for example: INCORRECT BLOCK COUNT I=1234567 (288 should be 0) FILE=ada0p7:/home/bob/important/business/memo.txt CORRECT? _ If the messages are tee'd somewhere, they can be easily postprocessed if that should be needed. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...