On Sat, Feb 4, 2012 at 5:40 AM, Kai Krakow <[email protected]> wrote: > Kai Krakow <[email protected]> schrieb: > >> Just happened while writing a huge avi file to my usb3 backup disk: >> >> [356036.596292] ------------[ cut here ]------------ >> [356036.596300] kernel BUG at fs/btrfs/inode.c:1588! > [...] >> >> btrfsck now finds many of these: >> >> jupiter ~ # btrfsck /dev/sde1 >> root 256 inode 12746 errors 400 >> root 256 inode 12747 errors 400 >> root 256 inode 12748 errors 400 >> root 256 inode 12749 errors 400 >> root 256 inode 17141 errors 400 >> root 256 inode 219966 errors 400 >> root 256 inode 224243 errors 400 >> root 256 inode 225245 errors 400 >> root 256 inode 225354 errors 400 >> root 256 inode 290639 errors 2000 >> root 256 inode 291751 errors 2000 > > It looks like the latter isn't a consequence of the former. I found kernel > commit f70a9a6b9 which is supposed to do something about "inode errors 400": > > commit f70a9a6b94af86fca069a7552ab672c31b457786 > Author: Miao Xie <[email protected]> > Date: Thu Jan 12 19:10:12 2012 -0500 > Btrfs: fix btrfsck error 400 when truncating a compressed > > It's actually the case for me that rsync writes to the device using mount > options "compress-force=zlib" and that rsync probably truncates files > sometimes when using the inplace option. > > So that occurence is explained. Can anyone tell how bad it is to have this > error? May the fs explode at some point or is it just an error I could > safely ignore for the moment? > > And what about the "inode errors 2000"? What's the 2000 standing for? >
As I understand it, Miao Xie's "Btrfs: fix btrfsck error 400 when truncating a compressed" patch was intended to address only one scenario that would lead to 400 errors. It was not intended to comprehensively address problems that generate inode 400 errors, nor will this patch fix the error once it encountered. As it stands right now, if you have errors reported by btrfsck, and you've exhausted the tools available for addressing errors (scrub and zero-ing out the log are the only two I know of), you only really have two options (until further tools such as btrfsck are released): (1) Run with the errors and cross your fingers. (2) Backup and restore onto a freshly formatted volume (there are some new tools available to extract data if you encounter errors). My personal preference is to backup and restore. With respect to the error codes, you have to look in the source for btrfsck.c. Inode errors are defined as I_ERR_<error>. 0x400 (1 << 8) errors are I_ERR_FILE_NBYTES_WRONG 0x2000 (1 << 13) errors are I_ERR_LINK_COUNT_WRONG The 400 inode errors have been common lately. I haven't seen as many 2000 inode errors. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
