Suggestion regarding fsck output enhancement

[Polytropon]

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, ...