On Fri, 2015-11-13 at 10:52 +0800, Qu Wenruo wrote: > You can provide the output of "btrfs-debug-tree -t 2 <dev>" to help > further debug. > It would be quite big, so it's better to zip it. That would contain all the filenames, right? Hmm that could be problematic because of privacy issues... > Although it may not help a lot, but at least I can tell you which > file > extents are affected. (By the hard way, I can only tell you which > inode > in which subvolume is affected, all in numeric form) > > And I could get enough info to determine what's the wrong type. > (data extent in metadata chunk or vice verse, or even system chunk is > involved) sigh... I mean... how can that happen, if nothing of the more recent things is used... I'd have guess others would have noted such a bug before. > > And is there any way to tell more certain, whether the balance > > would > > help or whether I'd just get more possibly even hidden corruptions? > > I > > mean right... well it would be painful to recover from the most > > recent > > backup, but not extremely painful. > > When extent and chunk type get wrong, only god knows what will > happen... > So no useful help here. If btrfs check already notices the mismatch, shouldn't it then be possible to set the correct type? > If the type mismatch errors are the only error output from fsck, then > scrub should not help or report anything useful. I see... > And at last, what's the kernel and btrfs-progs version? kernel 4.2.6 btrfsprogs 4.3
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
