[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ogfs-dev]Map OpenDLM to G-lock: lock name

> -----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?

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.

-- 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.
Opengfs-devel mailing list

[Index of Archives]     [Kernel]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Clusters]     [Linux RAID]     [Yosemite Hiking]     [Linux Resources]

Powered by Linux