All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-xfs@oss.sgi.com, lachlan@sgi.com
Cc: xfs-dev@sgi.com
Subject: hints on how to help debugging as FAQ entry (Re: invalid directory entry - bad magic number on inode)
Date: Tue, 12 Dec 2006 10:25:41 +0100	[thread overview]
Message-ID: <200612121025.42895.Martin@lichtvoll.de> (raw)
In-Reply-To: <457DFA6A.9050200@sgi.com>

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?"

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

  reply	other threads:[~2006-12-12  9:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-08 19:59 invalid directory entry - bad magic number on inode Martin Steigerwald
     [not found] ` <457D65A1.8030609@sgi.com>
2006-12-11 20:11   ` Martin Steigerwald
2006-12-12  0:40     ` Lachlan McIlroy
2006-12-12  9:25       ` Martin Steigerwald [this message]
2006-12-19 17:16         ` hints on how to help debugging as FAQ entry (Re: invalid directory entry - bad magic number on inode) Lachlan McIlroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200612121025.42895.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=lachlan@sgi.com \
    --cc=linux-xfs@oss.sgi.com \
    --cc=xfs-dev@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.