On Thu, Aug 07, 2014 at 10:51:15AM +0800, Qu Wenruo wrote:
> It seems that the patch is rejected in patchwork,

It was not me :)

> Could any one tell me the reason?

I'd understand that the patch is no longer needed after the original
problem went away, but it's not what you describe in your changelog.
>From that point the reason might not be compelling.

> >Above commit will cause disaster if someone try to mount a newly created but
> >later corrupted btrfs filesystem.

The generation after mkfs is something like 4 or 5, this means that the
corruption would have to happen in the first few transaction commits,
this is unlikely and the filesystem will be probably fairly empty at
that time.

If the concern is about corrupted generation counter itself in the
superblock, then yes this could hurt.

It's still possible to compare the 1st superblock with the copies, the
one at offset 64M is available in 99%, there are enough data to make a
decision what's actually corrupted. This could catch more corruption
than just the generation counter.

>From the output of btrfs-show-super:

generation              56392
chunk_root_generation   56392
cache_generation        56392
uuid_tree_generation    56392

the generation is duplicated several times, so a minimal patch could be
to do additional comparison with the others.

> >And before btrfs entered mainline, btrfs-progs has already superblock
> >checksum. See btrfs-progs commit: 5ccd1715fa2eaad0b26037bb53706779c8c93b5f
> >(superblock duplication by Yan Zheng).

The superblock checksum was not calculated the same way as in kernel,
but with the missing check this was not detected.

> >Before commit 5ccd17, mkfs.btrfs uses 16K as super offset, while current 
> >btrfs
> >uses 64K super offset, anyway old btrfs without super csum will not be
> >mountable due to the change of super offset.
> >
> >So backward compatibility is not a problem.

Superblocks at offset 16k are not supported anymore AFAICT.
--
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

Reply via email to