Anand Jain <Anand.Jain@xxxxxxxxxx> hat am 11. Juli 2012 um 09:13 geschrieben: > > > If this is a deliberate corruption can you pls share the test-case ? No. It's a real life corruption on a file system used to back up some servers. That's also why basics like aquota,awk etc. are found. But I expect it would be very hard to make a reproducible test case with error. (Usage: see PS: below.) > if not have you tried mount with recovery and the scrub. ? scrub> would be > preferred choice over btrfsck. I can scrub this file system. But isn't it a good test to try some recovery? A stable btrfs later should manage corruptions like this SIGSEGV and data loss. I expect a real life recover could cover more strange things than the test cases :) So it's your/ btrfs supporters choice. How far we should follow this issue. I did in between an image of the corrupted file system, so multiple recovery tries are possible. Best regards, Christian PS: I would bet that my kind of usage is a very good stress test for btrfs. - large file system "/backup" btrfs with compress enabled. Content of the file system: - ./server1 .... /server5 as directories - for each server the directory has a structure like this: backup-YYYY-DD-MM-HH:M New backups are created with: rsync -axvH --link-dest=/backup/server'n'/backup-...(old, last dir).. server:/ /backup/server'n'/backup-YYY-.../. This generates files with a large number of hard links. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
