UUIDs for PBC headers

[Chip Salzenberg]

In the use case where the same pbc exists in multiple places in a
filesystem (or is renamed during run, or lives on a filesystem without
a good definition of "same place"), it's necessary to detect when a
load is redundant.

I'm planning to require a UUID in the pbc header which would make each
pbc distinguishable from every other pbc. This would have no privacy
issues if it's done right, because the pbcs are identified, not the
parrot installations that create them.

Any problems here? Any suggestions for UUID code that's licensed
appropriately for use in Parrot?
--
Chip Salzenberg <ch...@pobox.com>

[Jeff Horwitz]

i know mod_parrot would benefit from this. one question though -- if a
redundant UUID is found, will the internals make the decision to load/not
load or will that be up to the HLL/embedding code?

> --
> Chip Salzenberg <ch...@pobox.com>
>

-jeff

[Chip Salzenberg]

On Mon, Oct 17, 2005 at 03:36:04PM -0400, Jeff Horwitz wrote:
> On Mon, 17 Oct 2005, Chip Salzenberg wrote:
> > I'm planning to require a UUID in the pbc header which would make each
> > pbc distinguishable from every other pbc.
>

> i know mod_parrot would benefit from this. one question though -- if a
> redundant UUID is found, will the internals make the decision to load/not
> load or will that be up to the HLL/embedding code?

The internals would make the decision. Speaking Perl 5 momentarily, the
semantics would be like 'require' rather than 'do'.
--
Chip Salzenberg <ch...@pobox.com>

[Chip Salzenberg]

On Mon, Oct 17, 2005 at 10:09:22PM -0400, Jeff Horwitz wrote:
> On Mon, 17 Oct 2005, Chip Salzenberg wrote:

> > Any problems here? Any suggestions for UUID code that's licensed
> > appropriately for use in Parrot?
>

> the UUID library in e2fsprogs might be appropriate. e2fsprogs is GPL, but
> lib/uuid has a separate and much more flexible BSD-style license.
> http://e2fsprogs.sourceforge.net/

Hey, neat.

On the other hand, the idea has been raised on IRC (by Joshua, IIRC)
that an MD5 or SHA256 would protect against corruption, and would also
incidentally make a dandy UUID.
--
Chip Salzenberg <ch...@pobox.com>

[Jeff Horwitz]

was there any discussion about what the checksums would be calculated on?
one benefit of UUIDs is that they are usually independent of the
underlying data they identify, and would therefore have no performance
penalty for larger files. i know it's only a one-time hit for PBC files,
and a minor one at that, but does this also apply for evals/compiles?

-jeff

[Chip Salzenberg]

I don't see a point in using it for evals/compiles.

As for the pbc file case: If you're making a pbc so large that hash
creation takes noticeable time, then just imagine how long _writing_
it will take? :-)
--
Chip Salzenberg <ch...@pobox.com>

[Jeff Horwitz]

On Tue, 18 Oct 2005, Chip Salzenberg wrote:

> On Tue, Oct 18, 2005 at 11:27:16AM -0400, Jeff Horwitz wrote:
> > On Tue, 18 Oct 2005, Chip Salzenberg wrote:
> > > On the other hand, the idea has been raised on IRC (by Joshua, IIRC)
> > > that an MD5 or SHA256 would protect against corruption, and would also
> > > incidentally make a dandy UUID.
> >
> > was there any discussion about what the checksums would be calculated on?
> > one benefit of UUIDs is that they are usually independent of the
> > underlying data they identify, and would therefore have no performance
> > penalty for larger files. i know it's only a one-time hit for PBC files,
> > and a minor one at that, but does this also apply for evals/compiles?
>
> I don't see a point in using it for evals/compiles.
>
> As for the pbc file case: If you're making a pbc so large that hash
> creation takes noticeable time, then just imagine how long _writing_
> it will take? :-)

this answers my question. :)

-jeff

[Joshua Hoblitt]

Also keep in mind that on modern hardware most hash algorithms are IO
limited. If you just wrote that file out to disk at least parts of it
are likely to be either buffered in the VM or cached there so the time
spent actually hashing the file (for large files) should be less then
the ammount of time it takes to physically write the file to disk.

Cheers,

-J

--