Re: RFC: block/loop.c & crypto

Albert D. Cahalan (acahalan@cs.uml.edu)
Sun, 22 Jul 2001 21:47:26 -0400 (EDT)


Andrea Arcangeli writes:
> On Sun, Jul 22, 2001 at 08:53:50PM +0200, Herbert Valerio Riedel wrote:

>> 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/