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

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



4 characters for a lock name seems too short for uniqueness.
Allowing multiple OGFS file systems is a good idea.
Using a UUID of the device containing file system is one approach
that has worked in the past, but that requires a longer lock name
(and a way to get UUIDs -- I think scsi provides that now.)

Daniel


On Sat, 2003-08-16 at 00:05, Stanley Wang wrote:
> 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



-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
_______________________________________________
Opengfs-devel mailing list
Opengfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opengfs-devel

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

Powered by Linux