Suggestion regarding fsck output enhancement

[Polytropon]

On Mon, 24 Aug 2020 18:27:36 -0400, Kurt Hackenberg wrote:
> On 2020-08-24 04:40, Polytropon wrote:
> 
> > 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
> 
> 
> That would be great. However, from my limited knowledge, I think it's 
> not easy.

I definitely agree. This is a non-trivial idea, especially
because the information needed would have to be obtained
in a "backwards search", and this surely adds complexity.
And I did not say it was easy, I just said it would surely
be a valuable information to have at that time. :-)



> I know how this works only in old, traditional Unix. As far as I know 
> it's the same for FreeBSD and its filesystem -- I think it has to stay 
> the same to preserve semantics -- but I don't know specifically.
> 
> I think a directory entry contains only a filename and an inode number. 
> All other information about the file is in the inode. (Well, apparently 
> the file type has been copied or moved from the inode to the directory 
> entry, probably for speed, but that doesn't matter here.)

Yes, that is a correct description. The core problem is that
the name (which the sysadmin might be interested in) is not
stored in the inode affected - it would have to be found out
in the corresponding "higher level structure" (directory)
that assigns names to inodes.

More information can be found in "man 5 fs" as well as in the
header files in /usr/include/ufs/ufs/, as well as of course
in McKusick's et al. article "A Fast File System for UNIX"
(or for that matter, probably any good UNIX technical
introduction book).



> The trouble is, an inode does not point back to any of the directory 
> entries that point to it.

That is _truly_ the point where things get complicated. :-)



> Far as I know, the only way to find names 
> associated with an inode is to search the whole filesystem, looking for 
> directory entries that contain that inode number. That could take a while.

There are tools that can do this quite conveniently, for example
the "inode list" program ils from "The Sleuth Kit". There are
other related tools such as ifind and istat which can obtain
liwer-level information regarding inodes, or to be precise,
help discover things within the "block <-> inode <-> directory"
composition of a file system, especially for cases like inodes
still "defined" (holding informations about file status and
used blocks), but being unallocated (not part of any directory,
therefore no name anymore) - tools like icat allow to "unwind"
this information and get the file content back. In this
specific case, this is what fsck does using the lost+found/
directory. But as I mentioned, there are cases where fsck
would do something "technically understandable" that would,
at a certain stage of disaster or recovery, be the wrong
thing, as the result would cause new problems and much more
work to actually recover data (typical example: file truncated
to size zero, or file filled with zero bytes, while intended
content is still "somewhere" on the disk).



> I had never heard of fsdb; I just read the man page. I don't see any 
> command to trace back from an inode to filenames. Did I miss something?

I learned about this specific tool when I had my personal "big
disaster moment" that brought me to this list more than 10 years
ago - "fdsb" was mentioned in the manual for WEGA, a System III
derived UNIX version for the EAW P8000 and P8000compact UNIX
workstations manufactured in the GDR during the 1980s. It was
a surprise to actually find this tool on a modern FreeBSD system
_and_ seeing it did what that old manual said. :-)


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