Sanidhya Solanki wrote on 2016/01/09 22:11 -0500:
On Sun, 3 Jan 2016 09:37:04 +0800
Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote:
Btrfs checksum are calculated in 3 different method:
1) Metadata: Per nodesize, stored in tree blocker header. (struct
btrfs_header->csum)
2) Data: Per sectorsize, stored in csum tree.
3) Superblock: Per 4K (fixed), stored in its header (struct
btrfs_super->csum)
I didn't the need to change any of them, as you are not changing any
of the csum behavior.
Good, that means I do not need to compare csums, just the data at the
end of the re-sizing operation.
I have finished most of the actual implementation details and
documentation for the re-size. However, before I undertake the last
part of the development, the integration of kernel-space and user-space,
as well as the integration between my code and the kernel code.
Stripe size only affect how btrfs does IO, not the csum size.
I have a question regarding this statement. I wanted to confirm that
the re-size will result in all the data blocks being re-written. Is
that correct?
AFAIK, Yes for stripe based RAID profile.
And I must admit that, the above statement is not completely right.
It also affect the on-disk data layout. But csum is still not affected.
Because the single statement above may also mean that all that needs to
be done is change one option and the kernel code takes care of the rest.
Just clarify that for me.
And since you are making the stripe size configurable, then user is
responsible for any too large or too small stripe size setting.
I have also left the option to use an un-conventional stripe size to the
user, for e.g., 768, 3072, 6144, etc.
Although personally I prefer to restrict to power of 2, but that's a
personal choice anyway.
Thanks,
Qu
Thanks.
--
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
--
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
