On Sat, May 28, 2011 at 09:16:17AM -0500, James Grossmann wrote: > On Sat, May 28, 2011 at 12:12 AM, James Grossmann <cctsurf@xxxxxxxxx> wrote: > > I recently decided to build a raid10 on my server. sadly shortly > > after I built it, a pair of the drives (mirroring each other) dropped > > errors at the same time, but upon a little revival are both actively > > working. I resynced the raid, but now I'm having difficulties > > reviving my xfs file system. > > I'm running ubuntu server 11.04, which includes xfsprogs 3.1.4. > > I have been attempting to get the git version or even 3.1.5 working on > > my system because I continue to get errors in attempting to xfs_repair > > the volume, but they don't seem to want to build for me. I kept > > getting a hang on inode 2111, but with some searching found the > > command: sudo xfs_repair -P -o bhash=1024 /dev/md0 to get me to inode > > 538638356. However, it fails at that point with the following > > message: > > corrupt dinode 538638356, extent total = 1, nblocks = 0. This is a bug. > > Please capture the filesystem metadata with xfs_metadump and > > report it to xfs@xxxxxxxxxxxx > > cache_node_purge: refcount was 1, not zero (node=0x3412410) > > > > fatal error -- 117 - couldn't iget disconnected inode Ok, not much to go on there. > > > > When I attempt the referenced command, it fails on me with the > > following error, I have attached the file it produces in dumping. > > udo xfs_metadump /dev/md/OlIronsides\:0 Olironsides.xfs.metadump > > cache_node_purge: refcount was 1, not zero (node=0x20b2420) > > xfs_metadump: cannot read root inode (117) > > cache_node_purge: refcount was 1, not zero (node=0x20b6020) > > xfs_metadump: cannot read realtime bitmap inode (117) > > *** glibc detected *** xfs_db: free(): invalid next size (normal): > > 0x00000000020d6000 *** That doesn't tell us much because the binaries are stripped. Building and using an unstripped binary shoul dgive a much more informative backtrace. .... > I was able to install the ubuntu Oneiric Ocelot's version of xfsprogs > (3.1.5), but I still get the same error at the same place. > Following the user guide, I was able to read inode 538638356: > > sudo xfs_db -c "inode 538638356" -c "print" /dev/md/OlIronsides\:0 > cache_node_purge: refcount was 1, not zero (node=0x2062420) > xfs_db: cannot read root inode (117) > cache_node_purge: refcount was 1, not zero (node=0x2066020) > xfs_db: cannot read realtime bitmap inode (117) > core.magic = 0x494e > core.mode = 0100755 > core.version = 2 > core.format = 2 (extents) > core.nlinkv2 = 1 > core.onlink = 0 > core.projid_lo = 0 > core.projid_hi = 0 > core.uid = 1000 > core.gid = 100 > core.flushiter = 3 > core.atime.sec = Wed May 25 22:44:12 2011 > core.atime.nsec = 569449438 > core.mtime.sec = Sat Dec 12 13:55:26 2009 > core.mtime.nsec = 000000000 > core.ctime.sec = Thu May 26 16:14:51 2011 > core.ctime.nsec = 201400000 > core.size = 5035163 > core.nblocks = 1230 ^^^^^^^^^^^^^^^^^^^ > core.extsize = 0 > core.nextents = 1 > 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.nodefrag = 0 > core.filestream = 0 > core.gen = 2106989417 > next_unlinked = null > u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,386750464,1230,0] so that looks like it has an extent and data blocks, so something has happened during the repair to zero block count of the in-memory version of the inode. That implies that the extent might be bad and was cleared earlier in the repair process, but without the repair output there i sno way to tell. > I'm having problems building the git xfsprogs, I get the following > error when I run make, I'm guessing I just don't have something > installed for the build. Have you pulled in all the automake, autoconf, etc packages? You caould also try running 'make realclean' first, too. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
