Date: Tue, 25 Aug 2020 14:53:39 +0200 From: Polytropon <freebsd@edvax.de> To: Kurt Hackenberg <kh@panix.com> Cc: freebsd-questions@freebsd.org Subject: Re: Suggestion regarding fsck output enhancement Message-ID: <20200825145339.df531ec6.freebsd@edvax.de> In-Reply-To: <12f154c3-078f-401d-6a48-dc2f700a4d1d@panix.com> References: <20200824104017.4c241ec0.freebsd@edvax.de> <12f154c3-078f-401d-6a48-dc2f700a4d1d@panix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200825145339.df531ec6.freebsd>