>> security is not the issue; it's more of practical terms... since
>> 512 byte seems to be the closest practical transfer size (there
>> isn't any smaller blocksize supported with linux) it seems natural
>> to use that one....
>
> to me it sounds more natural to use the 1k blocksize that seems to
> be backwards compatible automatically (without the special case),
> the only disavantage of 1k compared to 512bytes is the decreased
> security, so if the decreased security is not your concern I'd
> suggest to use the 1k fixed granularity for the IV. 1k is also the
> default BLOCK_SIZE I/O granularity used by old linux (which
> incidentally is why it seems backwards compatible automatically).
Being backwards compatible with non-Linus kernels is less important
than choosing a block size that is fit for all block devices.
Disks, partitions, and block-based filesystems are all organized
in power-of-two multiples of 512 bytes.
The smaller size can handle the larger size; the reverse is not true.
We all have to live with the size choice until the end of time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/