On Wed, May 4, 2011 at 5:39 AM, Martin Schitter <m...@mur.at> wrote: > Am 2011-05-04 04:18, schrieb Fajar A. Nugraha: >>> >>> could you give me some advice how to debug/report this specific >>> problem more >>>> >>>> precise? >> >> If it's not reproducible then I'd suspect it'd be hard to do. > > the last working snapshot is from 2011-05-02-17:13. i can reproduce this > file system corruption on one specific file in any hourly snapshot later.
That's not surprising, any later snapshots will be sharing the same corrupted block. > that looks very unplausible to me. there is an RAID1 layer beneath btrfs in > our setup and i don't see any errors there. That doesn't rule out the possibility of corruption when it was written in the first place, or some similar problem that the raid1 faithfully reproduced on both mirrors. That's not to say that it's impossible that the problem is in btrfs, just that it's not the only plausible possibility. > and the 'nodatasum' option should also ignore csum issues.-- isn't it? No, it only affects writing new checksums; any existing checksums are still checked. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
