Suggestion regarding fsck output enhancement

Polytropon freebsd at
Mon Aug 24 15:48:20 UTC 2020

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/
> > 	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)

If the messages are tee'd somewhere, they can be easily
postprocessed if that should be needed.

Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...

More information about the freebsd-questions mailing list