From: Alexander Viro (viro@math.psu.edu)
Date: 03/16/00-02:39:59 PM Z
Date: Thu, 16 Mar 2000 15:39:59 -0500 (EST) From: Alexander Viro <viro@math.psu.edu> Subject: Re: (reiserfs) reiserfs and knfsd and NFSv4 and volatile file handles Message-ID: <Pine.GSO.4.10.10003161529570.4547-100000@weyl.math.psu.edu> On Thu, 16 Mar 2000, Andi Kleen wrote: > That is what they use all the ugly "has rescheduled" flags for. The entry > also has a "recently deleted" flag that is checked (hidden). When the tree > is rebalanced inbetween they catch that with a relookup (because offset > stays a fixed position). When you insert new entries before the current > filldir offset inbetween you lose (but standard ext2 is no better in that > as far as I can see). In the 2.3 version they use generation counts for ext2 relies on directory being locked during readdir(). I'm not sure that I understand what you mean. Notice that ext2_readdir() used to have a nasty race - it checked for ->i_version (which is constant), but failed to check for ->f_version (which can change along with ->f_pos if somebody does lseek() on descriptor of the same struct file). So it didn't redo the sanity checks on ->f_pos if somebody did lseek() and that gave a fairly nasty DoS - ext2 decided to remount the thing r/o, since it thought that on-disk structure was fucked. > most things, so they can more easily find out if a object changed. > As far as I can see the reiserfs readdir handles all races the ext2 > readdir handles. > > [Note that I'm no reiserfs hacker, that just came from my own reading > of the source. Maybe it is better you apply the patch and do some > real RTFS ;] <shrug> if you know how to pack more than 100-odd working hours into the week - share, lot of people will be very grateful. > -Andi > > P.S.: The loopback device in 2.3.51 seems to be still very unstable > when accessing block devices. I get weird hangs all the time. It > looks like it is leaking some important inode semaphore or similar, > because all new processes hang and then the remaining processes > start to block one after another as they try to do file system > accesses. Hmm... That's the path I didn't change at all. I'll look at it. Sigh...
This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:08 AM Z CST