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
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
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?"
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7