hints on how to help debugging as FAQ entry (Re: invalid directory entry - bad magic number on inode)

Martin Steigerwald
2006-12-12T09:26:53Z

Am Dienstag 12 Dezember 2006 01:40 schrieb Lachlan McIlroy:

> > You are welcome. Without further info reporting it to the bugtracker
> > doesn't make much sense to me. I will keep an eye on it. If it
> > happens again, I will try the hints you gave me. I run xfs_check
> > anyway and thus can easily give it a "-v >xfs_check.txt". I thought I
> > would have to use xfs_db stuff to get further info.
>
> Now that you mention it, printing out the inode in xfs_db might be
> useful.

Hello Lachlan,

well I can do that too... my problem is just: As I use the notebook for
daily work I have to fix it up quickly when problems arise. So usually I
can not afford to report first and await instructions on what to do. I
also currently often have no storage space left to store the complete
partition onto.

So ideally I have some hints on how to help debugging before an incident
happens. I think this would make a nice FAQ entry, too.

It could contain:

1) xfs_check -v <device>
2) xfs_check -v -i <inode> <device>
3) xfs_db stuff
4) probably some hints to determine a useful range for dd / ddrescue from
xfs_check output so that people with either very large partitions or low
storage space can just copy a part of the defect partition for
inspection. Well if thats useful. A complete partition would still be
better cause it is possible to use the XFS tools on it
5) probably some hints on how to store a partition in a file with
compression... somewhere along the lines of piping dd into bzip2 and
bzip2 into a file. maybe "cat /dev/hda1 | bzip2 >mypartition"

What do you think?

Those hints could help XFS developers to get useful bug reports...

I am willing to collect the hints and writing a FAQ entry about it that
you can include in your FAQ.

Well that would probably basically be an extension to:

" Q: What information should I include when reporting a problem?"