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>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200824174815.7447f0d3.freebsd>