--myN6XCtPygAIW5jc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 20, 2005 at 08:26:37PM +0200, Pawel Jakub Dawidek wrote:
> "This whole mess" is something like:
>=20
> 	sector0 [encrypted enckey+encrypted mackey+IV+MAC]
> 	sector1..n [encrypted data]
>=20
> So you write few sectors at once. I'll find out soon how
> reliable it is.

Based on what? Empirical testing with specific hardware?  That might
tell you something about your hardware, or even about disks in
general, but whatever you learn can't be generalised to all the
possible places a block device driver might be stacked.  As a simple
illustration, what if this is layered atop a striped volume, and your
"few sectors" happen to span across an underlying stripe boundary over
two different disks?

There's no particularly strong guarantee that even single-sector
writes to a single disk are atomic. We all presently depend on this
assumption, largely unavoidably, but it may not be true.

Providing integrity mechanisms (keyed or otherwise) on top of this
basically needs to involve a transactional model, via a journal or
some other indirect-storage construction, where the transaction is
only complete and valid once the data and hmac agree.  Once you have
to go this far anyway, you can address even single-sector
atomicity/errors.

Some systems do this at the fs or application layer. It would be nice
to have a generic block device with these capabilities, along with a
clear way for upper layers to indicate transaction boundaries.

--
Dan.
--myN6XCtPygAIW5jc
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (NetBSD)

iD8DBQFDCAIWEAVxvV4N66cRAlIUAKDAf8sIxenUrGGDA2El4yQMc0dIwwCfVgZS
Krls01grbCBqb7FuAgZ2XSM=
=OXGZ
-----END PGP SIGNATURE-----

--myN6XCtPygAIW5jc--