--TRYliJ5NKNqkz5bu
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 21, 2005 at 02:24:54PM +1000, Daniel Carosone wrote:
+> 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.
+>=20
+> 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?
+>=20
+> 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.

If it isn't true, then implementation proposed by Roland is not possible,
because you can write new MAC, old MAC and half of the sector.

You are right, that there is no guarantee for atomicity I'm talking
about, but if it is in 80% if cases we can cope. I prefer to give
a tool to the user, so he is able to fix single block manually:

	# fixit dev blockno

because in most cases such protection will be used for laptops and then
user know if there was a crash (and he should expect one broken block)
or not. I can even help him with this and mark device as clean on last
write-close and only allow/advice using this tool when device is drity.

+> 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.
+>=20
+> 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.

My other idea is simlar to Roland's, but is very space-consuming:

	1. write new mac [one sector]
	2. write data [one sector]
	3. write new mac [one sector]

it should be safe when we assume single-sector atomicity. There is small
performance impact (we don't have to wait for read operation to complete),
but there is huge space impact (you can use only 33% of your disk).

And here goes optimization:

	1. sector0: write mac(sector1)+mac(sector2)+... [one sector]
	2. sector1: write data [one sector]
	3. sector2: write data [one sector]
	...
	n. sectorn+1: write mac(sector1)+mac(sector2)+... [one sector]

Performance impact is smaller, space impact is also smaller.

Hmm, I like this idea...

PS. Single-sector atomicity could not be possible with things like raid3
    devices, where very sector contains one sector from every component.

--=20
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd@FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!

--TRYliJ5NKNqkz5bu
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDCFYlForvXbEpPzQRAru5AKDvoazEbhQoV6tRfiT0ExJLzA1r2QCgqHjc
Z40z+HJ3NLOUuJqSpBwJwQE=
=syt5
-----END PGP SIGNATURE-----

--TRYliJ5NKNqkz5bu--