xfs
[Top] [All Lists]

Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes)

To: peyytmek@xxxxxx
Subject: Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes)
From: Timothy Shimmin <tes@xxxxxxx>
Date: Fri, 03 Nov 2006 10:58:31 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <200611012255.46008.peyytmek@xxxxxx>
References: <200611012255.46008.peyytmek@xxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
Hi there,

Sorry about not getting back to you.

The inode details you sent me look reasonable to me (AFAICS).
However, the inode that we are processing which has problems
is probably coming from the log.
Basically, during log replay we reinstate metadata such as inodes,
inode buffers,
and later process an unlinked-list which this inode appears to be on.
It's during the truncating (as part of inactivating the inode) that we have 
problems
when looking at its extents.

You should be able to see this inode in the log if you use:
# xfs_logprint -ti device
(or possibly I guess
# xfs_logrpint -tibo device - if the inode is in a buffer of inodes)
I'd be curious to see this.

My thoughts for a plan of action were either:
(1) forget the log and do an "xfs_repair -L" to zero it out and repair
or
(2) somehow try to do a mount which avoids the unlinked list processing
(an older kernel (pre May 26)  would do this because of a bug in recovery);
then unmount, then do a normal "xfs_repair"
or
(3) we try to stop this particular inode from being processed in the
unlinked-list inode processing during mount; unmount; repair and then mount 
again

The simplest is to do option (1). However, it means that any other outstanding
metadata changes would be lost.
Option (2) might be a goer but you need such a kernel and in that case it
won't do any unlinked processing for a group of such inodes (one's hashed to
that bucket in the AGI's). I'm unsure on how to stop this unlinked processing
otherwise.
Option (3) I'm unsure as how to do. Also, there could be more inodes in
the same boat which could cause recovery to crash.

May be others have suggestions.

Regards,
Tim.

--On 1 November 2006 10:55:43 PM +0000 peyytmek@xxxxxx wrote:

Hello,
Thanks for your last answer. Since you didn't answer my email for 2 weeks i
thought you might have deleted it accidently

Here's the email conversation:

> Hello.
> Thanks for your answer.
>
> That's what i have: dmesg print with kernel-2.6.16-gentoo-r3 and an print
> of xfs_bg.
>
>> You could print out the offending inode with xfs_db to show us
>> what it looks like: $xfs_db -r /dev/hdb1 -c "inode 950759" -c "print".
>
> I don't know what you mean with it but i added it anyway. (done with
> kernel-2.6.18-gentoo if it matters)
>
> xfs_db:
>
> CLX ~ # xfs_db -r /dev/hdb1 -c "inode 950759" -c "print"
> core.magic = 0x494e
> core.mode = 0100644
> core.version = 1
> core.format = 3 (btree)
> core.nlinkv1 = 0
> core.uid = 1000
> core.gid = 100
> core.flushiter = 0
> core.atime.sec = Sun Aug 27 14:56:52 2006
> core.atime.nsec = 657389250
> core.mtime.sec = Sun Aug 27 16:29:40 2006
> core.mtime.nsec = 080196250
> core.ctime.sec = Thu Oct  5 01:17:40 2006
> core.ctime.nsec = 976565958
> core.size = 32071862
> core.nblocks = 7833
> core.extsize = 0
> core.nextents = 28
> core.naextents = 0
> core.forkoff = 0
> core.aformat = 2 (extents)
> core.dmevmask = 0
> core.dmstate = 0
> core.newrtbm = 0
> core.prealloc = 0
> core.realtime = 0
> core.immutable = 0
> core.append = 0
> core.sync = 0
> core.noatime = 0
> core.nodump = 0
> core.rtinherit = 0
> core.projinherit = 0
> core.nosymlinks = 0
> core.extsz = 0
> core.extszinherit = 0
> core.gen = 0
> next_unlinked = null
> u.bmbt.level = 1
> u.bmbt.numrecs = 1
> u.bmbt.keys[1] = [startoff] 1:[0]
> u.bmbt.ptrs[1] = 1:185933

And now:

xfs_db -r /dev/hadb1 -c "fsb 185933" -c "type bmapbtd" -c "p"

to look at the 28 extent records.

--Tim

Here's the content of my last Email


Hello, thanks again for your fast answer
Sorry for the double post last time.
here it comes


CLX ~ # xfs_db -r /dev/hdb1 -c "fsb 185933" -c "type bmapbtd" -c "p"
magic = 0x424d4150
level = 0
numrecs = 27
leftsib = null
rightsib = null
recs[1-27] = [startoff,startblock,blockcount,extentflag] 1:[0,185637,16,0] 2:
[16,185537,8,0] 3:[24,185718,8,0] 4:[32,185706,8,0] 5:[40,185836,8,0] 6:
[48,185848,16,0] 7:[64,185865,16,0] 8:[80,185882,8,0] 9:[96,185899,16,0] 10:
[112,185916,16,0] 11:[340,185934,2,0] 12:[342,4768704,1320,0] 13:
[1662,4770389,239,0] 14:[1901,4770919,264,0] 15:[2165,4771391,165,0] 16:
[2330,4771860,227,0] 17:[2557,4861204,351,0] 18:[2908,4861800,257,0] 19:
[3165,4862282,349,0] 20:[3514,4862934,230,0] 21:[3744,4863506,383,0] 22:
[4127,4864141,348,0] 23:[4475,4864871,228,0] 24:[4703,4865358,268,0] 25:
[4971,4865882,593,0] 26:[5564,4866818,339,0] 27:[5903,4867729,1928,0]






<Prev in Thread] Current Thread [Next in Thread>