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

On Mon, Aug 22, 2005 at 10:09:11AM +0200, Pawel Jakub Dawidek wrote:
> There are no small writes. visible sector size for upper layers is 8kB.

Ah. Ok, something else I'd missed.  (As an aside, I've several times
got the impression I'm joining in part-way through a discussion of
your specific design or project - as opposed to the gbde thread -
where some of these preliminaries had been established earlier
elsewhere.)

This means you should only really need integrity (MAC) of the entire
data block, old or new - this was the source of my previous confusion
over your (0, 1..n, n+1) layout and transactional model, since I
assumed in the first reading that this was what you were trying to do.
You clarified that you instead had individual MACs per sub-block, and
could maintain integrity assuming the underlying hardware was atomic
at this resolution.

However, at this point you've negated one of your previous tenets.  If
the upper layer sees each MAC+data+MAC block as a single data block,
you have to have transactional integrity *at that resolution*.  Your
mechanism allows you to reproduce partial write results (with either
old or new mac, per physical sector) to that upper layer - but only
the full old or new 8k data value is valid to the filesystem.

So I maintain that you need to think and present more carefully on the
transactional model you're trying to achieve.

> This will take 12% of your disk, which is absolutely acceptable for me.

Me too, if the cost provides the needed functionality.  There are also
performance (largely seek-related) costs to consider in any design.

> +> How are you preventing replay of old MAC+data+MAC groups, or of
> +> specific data blocks and MAC entries within a group?  Either seems to
> +> involve some extra metadata (a txn counter and MAC-sector-MAC? in the
> +> MAC sectors or elsewhere?), with corresponding storage and transaction
> +> overhead.
> +>=20
> +> How many MACs can you fit in a sector (ie, is N large enough to be
> +> useful), especially with the above taken into account?
>=20
> Unfortunately it won't handle old MAC+data+MAC problem...

Unfortunately, that's *exactly* the replay problem I infer from the
thread Subject: line (and that most other readers and eventual
'customers' are likely to).  If you have a different problem statement
you're trying to solve, fair enough, but I missed it along with the
other aspects I alluded to above.

> There is no counter you can add to the block's metadata to fix it.

There are a number of potential designs, some of which I've alluded
to, and possibly including new ones. I've been trying to discover
which, if any, of these you're pursuing - or to point out that you're
missing the (assumed) target if you've not taken these issues into
consideration.

If your target is a simpler problem (as cgd(4)'s is, for example, in
no small part as a recognition of the complexities this discussion is
highlighting) that's fine - as long as everyone has a clear
understanding of exactly what your system is and isn't.

> While your comments are valid and I appreciate them (I really do),
> I entered this discussion to actually find some secure and reliable
> way to provide device-level integrity verification with your help, guys.
> And this conversation could be even more productive, if you stop
> treating me as your enemy:)

Please don't mistake constructive criticism, investigative
questioning, or the need to defend a thesis, as enmity. None is
intended.

--
Dan.



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

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

iD8DBQFDCn6WEAVxvV4N66cRAtfkAKDnnDpFTGGel6Bwf39xx1imQ7un6QCfXS8V
19OvgtJMAjlxZltou8twCgc=
=H7ip
-----END PGP SIGNATURE-----

--P75d7mFgfYjpUjsN--