On Sat, May 14, 2016 at 07:42:26AM +0800, Qu Wenruo wrote: > > For fsck code, we can go forth and back to fix them. In fact I don't > > think fsck could work out anything, as superblock checksum has _matched_ > > but the values inside superblock are invalid, in this case we cannot trust > > other parts in this FS image, then how can we expect fsck to fix it by > > reading > > other parts? > > For rw fsck, that may cause huge problem and I agree with you on error out. > But for ro fsck, it's a little overkilled for me. > > Currently, if we found error in extent tree, we still continue checking > fstree, to shows what is really wrong. > > And for case like btrfs-image restored images, its dev extents doesn't > even match with its chunk (may be it's already fixed?), but that's not a > big problem for ro btrfsck, and we can go on without problem. > > So the same case is here for ro btrfsck. > As long as that's ro btrfsck, we could just continue as we don't really > need the total_bytes in superblock.
AFAICS super_block->total_bytes is used in btrfs_alloc_chunk and in several places in mkfs, but 'check' does not look at the value at all, so warning for the read-only should be ok. -- 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
