Re: Race with inodes in I_FREEING state

[Livio Baldini Soares <livio@ime.usp.br>]

  Hey!

Andreas Dilger writes:
> On Jun 13, 2003  15:02 +1000, Neil Brown wrote:
> > > On Friday June 13, livio@ime.usp.br wrote:
[...]

> > >   Does this not also happen in  version 2.4.20? Can anybody tell me if
> > > my logic is  wrong, or if I'm just plain doing  something stupid in my
> > > FS?
> > 
> > Yep.  It sound like the same race.  I wasn't going to submit a 2.4
> > patch until the 2.5 one went in.  I hope to submit the 2.4 equivalent
> > when 2.4.22-pre opens up.

  Ah, _great_! Thanks a lot Niel.

> Sigh, we've just spent a week chasing exactly this same race in Lustre
> on 2.4.  It also stores pointers to shared data in the inode (DLM locks)
> which are freed when clear_inode() is called.  We fixed it only a few
> hours ago by not matching our hashed locks if they are not for the same
> inode _pointer_ instead of just for the same inode _number_/generation,
> which is what the distributed lock name is.

  Humm.. interesting  work around.  Except,  my FS, the hashed  data I
have  in the  inode's private  parts has  no idea  that an  inode even
_exists_.  Guess I'll  have to  start keeping  a back  pointer  to the
inode, until this is fixed. Darn.

> If only Livio had posted this email last week ;-).

  Oops, sorry about that! :-P But  you too, could of sent this earlier
and saved me 2 days of  doing absolutely nothing except looking into a
monitor ;-)

  Cheers!!

--  
  Livio B. Soares