On 4/24/15 5:50 AM, Rick Macklem wrote: > John Baldwin wrote: >> On Thursday, April 23, 2015 05:02:08 PM Julian Elischer wrote: >>> On 4/23/15 11:20 AM, Julian Elischer wrote: >>>> I'm debugging a problem being seen with samba 3.6. >>>> >>>> basically telldir/seekdir/readdir don't seem to work as >>>> advertised.. >>> ok so it looks like readdir() (and friends) is totally broken in >>> the face >>> of deletes unless you read the entire directory at once or reset to >>> the >>> the first file before the deletes, or earlier. >> I'm not sure that Samba isn't assuming non-portable behavior. For >> example: >> >> From >> http://pubs.opengroup.org/onlinepubs/009695399/functions/readdir_r.html >> >> If a file is removed from or added to the directory after the most >> recent call >> to opendir() or rewinddir(), whether a subsequent call to readdir() >> returns an >> entry for that file is unspecified. >> >> While this doesn't speak directly to your case, it does note that you >> will >> get inconsistencies if you scan a directory concurrent with add and >> remove. >> >> UFS might kind of work actually since deletes do not compact the >> backing >> directory, but I suspect NFS and ZFS would not work. In addition, >> our >> current NFS support for seekdir is pretty flaky and can't be fixed >> without >> changes to return the seek offset for each directory entry (I believe >> that >> the projects/ino64 patches include this since they are breaking the >> ABI of >> the relevant structures already). The ABI breakage makes this a very >> non-trivial task. However, even if you have that per-item cookie, it >> is >> likely meaningless in the face of filesystems that use any sort of >> more >> advanced structure than an array (such as trees, etc.) to store >> directory >> entries. POSIX specifically mentions this in the rationale for >> seekdir: >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/seekdir.html >> >> One of the perceived problems of implementation is that returning to >> a given point in a directory is quite difficult to describe >> formally, in spite of its intuitive appeal, when systems that use >> B-trees, hashing functions, or other similar mechanisms to order >> their directories are considered. The definition of seekdir() and >> telldir() does not specify whether, when using these interfaces, a >> given directory entry will be seen at all, or more than once. >> >> In fact, given that quote, I would argue that what Samba is doing is >> non-portable. This would seem to indicate that a conforming seekdir >> could >> just change readdir to immediately return EOF until you call >> rewinddir. >> > Loosely related to this, I have been tempted to modify readdir() to > read the entire directory on the first readdir() for NFS, to avoid the > readdir()/unlink() problem. I did find a bug in our readdir/seekdir that makes it a lot worse... We reload the kernel's idea of the directory every time we do a seekdir() back, even if it's within the same block, which makes us a lot more susceptible to the problem.. making it not do that unless the new location is in another block made it work on directories with up to several thousand files (with 32k blocksize) before failing. With that bug it's possible do make every seekdir() produce failures even in a directory of just 3 files.. The downside is that the client continues to see the old contents of the block even though he has done a seekdir() within it. > > My concern was doing this for a very large directory. Maybe it could be > done for directories up to some size? > > rick > >> -- >> John Baldwin >> _______________________________________________ >> freebsd-current_at_freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe_at_freebsd.org" >> > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" > >Received on Fri Apr 24 2015 - 03:10:46 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:57 UTC