On Tue, 2016-01-05 at 11:44 +0100, David Sterba wrote: > We have a full 32 bit number space, so multiples of power of 2 are > also > possible if that makes sense. Hmm that would make a maximum of 4GiB RAID chunks... perhaps we should reserve some of the higher bits for a multiplier, in case 4GiB would ever become too little O;-)
> In general we don't need to set additional > limitations besides minimum, maximum and "minimal step". And that can/should be done in the userland. > > Are there any concerns/constraints with too small/too big chunks > > when > > these play together with lower block layers (I'd guess not). > > I don't think so. Well I was mainly thinking about dm-crypt, that uses 512B blocks and in fact that size wouldn't be easy to change, as (IIRC) larger block sizes make XTS less secure. Obviously *this* isn't anything that btrfs would have to worry about, especially as we're anyway on a higher block layer level,.. but it just reminded me that there can be cases where too large / too small may actually cause issues. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
