On 2/8/11 12:06 AM, Ryan Roh wrote: > Dear Eric, > > Thank you for kind reply. > > The XFS partition can be mounted after xfs_repair with -L option. Ok. > Actually, the debug option was turned off. So the assert is not called. > Anyway the level was equal to root level of b-tree. So if I change the code > like in the below then XFS mount display the message to repair partition > with xfs_repair. > > /* > * If we went off the root then we are seriously confused. > */ > If (lev < cur->bc_nlevels) > return EFSCORRUPT; > //ASSERT(lev < cur->bc_nlevels); > > > Kernel oops can be replayed with metadump and restored image. But when I > tested it with 2.6.33.6 (FC13) then mount failed with " mount: Structure > needs cleaning" message. Ok, as it should. So this has been fixed upstream, as part of Christoph's btree rework. These 2 commits were part of a larger series, but they put this particular error handling in place: 8df4da4a0a642d3a016028c0d922bcb4d5a4a6d7 [XFS] implement generic xfs_btree_decrement 637aa50f461b8ea6b1e8bf9877b0d13d00085043 [XFS] implement generic xfs_btree_increment > And Would you please let me know how I can share the metadump file with > others? It is too big to send through the e-mail. Can I use the FTP server > to share it? I think there is no need, since you have shown that the bug is fixed upstream; I should have suggested that myself, but thanks for testing it. It's always a good idea to test upstream before reporting bugs to the list for old kernels; if bugs are fixed already there is no need to report them here or in bugzilla. -Eric > And I got the hint about the patch for vmap cache aliasing issue from Dave > Chinner and I trying to apply it. > "[GIT PATCH] Fix XFS to work with Virtually indexed architectures" : > http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-02/msg10227.html > > Thanks, > Ryan. > > > -----Original Message----- > From: Eric Sandeen [mailto:sandeen@xxxxxxxxxxx] > Sent: Tuesday, February 08, 2011 2:40 PM > To: Ryan Roh > Cc: xfs@xxxxxxxxxxx > Subject: Re: segmentation fault during mount > > On 2/7/11 11:12 PM, Ryan Roh wrote: >> Dear Eric, >> >> I don't know how I can make correct form to answer for this thread >> because I'm newbie here. Sorry. >> >> Anyway, this issue was happened from returned HDD from customer which >> was used our PVR STB. And our STB has toggle power switch so I think >> user turned off the power during recording something. > > Ok, so you're not sure what happened to the hard drive before this, then. > > Other Samsung folks have reported problems after intentionally testing the > filesystem under harsh conditions such as poweroff or USB unplugs, so I just > wondered... > > It seems plausible to me that this could be corruption from lack of proper > barrier support, and a poweroff or usb unplug (without barrier support) > could cause that. > > Mounting a corrupted filesystem should never oops the kernel though, so that > is a bug. If you can provide an xfs_metadump image of the filesystem, > someone might be able to investigate further. > > Does the mount failure persist after an xfs_repair (without using -n?) > > If you wish to keep the original filesystem intact, you can make an > xfs_metadump image of the filesystem, run xfs_mdrestore to create a new > metadata image from that dump, run xfs_repair against that, and try to mount > the result. > > Does samsung run with CONFIG_XFS_DEBUG enabled? Otherwise, this: > > /* > * If we went off the root then we are seriously confused. > */ > > ASSERT(lev < cur->bc_nlevels); > > would be a no-op: > > #ifndef DEBUG > #define ASSERT(expr) ((void)0) > ... > > (As a side note, running with CONFIG_XFS_DEBUG in production is not > recommended.) > > However, I'm not quite sure that's what you are hitting, if you tripped an > ASSERT you should have seen "Assertion failed" in the messages. This > appears to be a null pointer dereference in xfs_free_ag_extent(). > > -Eric > > >> Thanks, >> Ryan. >> >> >> -----Original Message----- >> From: Eric Sandeen [mailto:sandeen@xxxxxxxxxxx] >> Sent: Tuesday, February 08, 2011 1:45 PM >> To: Ryan Roh >> Cc: xfs@xxxxxxxxxxx >> Subject: Re: segmentation fault during mount >> >> On 2/7/11 5:01 AM, Ryan Roh wrote: >>> Dear Members, >>> >>> I'm using XFS based on STMicro SH4 based chip (STi7105). >>> >>> and I have some issue on xfs log mounting. >>> >> >> Were the errors after any sort of harsh testing of the filesystem, >> such as usb disconnects or power off? >> >> Or was this after a clean unmount? >> >> -Eric >> >>> >>> 1. chip : sh4 STi7105 >>> >>> 2. HDD : 320GB USB HDD USB 2.0 port. >>> >>> 3. OS : Linux 2.6.23.17 + patch for fixing cache aliasing issue. >>> >>> 4. XFSProgs version : 3.1.1 >>> >>> >>> >>> mounting and repairing log in the below. This segmentation fault is >>> caused by >>> >>> the assert in xfs_alloc_increment function of xfs_alloc_btree.c file. >>> The btree >>> >>> level is equal to root level in the below code. >>> >>> >>> >>> /* >>> >>> * If we went off the root then we are seriously confused. >>> >>> */ >>> >>> ASSERT(lev < cur->bc_nlevels); >>> >>> >> >> ... >> > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
