On Friday 03 November 2006 00:58, you wrote:
Hello again
Thanks for your email
First of all, everytime I do xfs_logprint /dev/hdb1, with -ti or -tibo
or mounting the partition with a kernel pre May 26 (kernel-2.16.3-gentoo-r3)
or even xfs_repair -L /dev/hdb1 it's always the same. my terminal just freezes
There is also nothing in /var/log/messages
Well, I'm going to try my hdd in another computer with a different
ide-controller. maybe that's the problem althought i doubt it would really
work that way out.
Bye,
D.H.
> 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]
|