Suggestion regarding fsck output enhancement

[Arthur Chance]

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.