| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
On Sat, 2003-08-16 at 02:11, Cahill, Ben M wrote:
> > -----Original Message-----
> > From: Stanley Wang [mailto:stanley.wang@linux.co.intel.com]
> > Sent: Thursday, August 14, 2003 8:37 PM
> > To: opengfs-devel@lists.sourceforge.net
> > Subject: RE: [ogfs-dev]Map OpenDLM to G-lock: lock name
> >
> >
> > On Fri, 2003-08-15 at 01:36, Cahill, Ben M wrote:
> > [snip]
> > > Hmmm, maybe the value within the OpenDLM lockname should be a 4-char
> > > (8?) hash of the locktable string?? This way, the user/admin could
> > > enter a real cidev /dev/cidevxxx string for memexp, and be
> > able to use
> > > the same string for opendlm?? Stanley was thinking about using the
> > > last 4 characters, but a hash would be more robust, with fewer ways
> > > for the user/admin to fall into a trap (e.g. /dev/0cidev vs
> > > /dev/1cidev).
> > My thought in this point: If we use the last four character
> > as identity, we
> > could tell the user explicitly. If we use a hash value, we
> > couln't tell when
> > the collision would occur. Any suggestion?
>
> Yes, it would be a little tougher to *predict* a collision, but ...
>
> Within the lock module, we need to check the uniqueness of the string
> (*after* hashing, or *after* masking all but last-4-chars), and refuse
> to mount if the string (as processed) is not unique (against other
> filesystems mounted on *this* machine, which is the total scope of our
> ability to determine uniqueness). I think the hash makes it less
> likely that there would be a collision (even if the user continues to
> use the same string that he's used for memexp, which had no
> 4-last-char restriction), and gives the user/admin more flexibility in
> contents of the field. 8-char or longer hash would make a collision
> even less likely. Is there any advantage to using fewer than the
> total 31 available chars in the lockname?
Yeah, we could double check the hash value and whole locktable name to
avoid collision.
>
> Either way, we'll need to update documentation (HOWTO(?), man pages),
> to describe what's going on, and issue a meaningful error message when
> a collision occurs, perhaps including *both* of the original,
> unprocessed strings, as well as the colliding hash/last-4-char
> results.
Sure. Of course we should update the corresponding docs.
Thanks for your great suggestion :)
>
> -- Ben --
>
> Opinions are mine, not Intel's
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Opengfs-devel mailing list
> Opengfs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opengfs-devel
--
Opinions expressed are those of the author and do not represent Intel
Corporation
"gpg --recv-keys --keyserver wwwkeys.pgp.net E1390A7F"
{E1390A7F:3AD1 1B0C 2019 E183 0CFF 55E8 369A 8B75 E139 0A7F}
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Opengfs-devel mailing list
Opengfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opengfs-devel