Re: ZFS vs Samba Debugging Results ... Need Help.

On Fri, 2007-07-06 at 01:19 -0400, Brian Donnell wrote:
> I did read the comment, and I've been running tests with zfs, ntfs,
> and ufs samba shares to see if anything bad is happening without those
> replacement functions.  Dropping the connection between computers down
> to 10mbit I'm not having any problems with directories containing a
> couple thousand files.  I can't reliably test any slower of a
> connection.  Maybe it's the speed of the computer or the speed of the
> connection, but I'm not seeing any issues.  With the replacement
> functions in ntfs can't be shared without core dumping either.  Are
> these replacement functions perhaps not needed anymore?  Or am I just
> missing something?  But ever since I removed those replacement
> functions on a 100mbit network I've seen, literally, a 10 fold
> increase in speeds writing to my FreeBSD samba shares from Windows XP.
> Perhaps that's just coincidence, but it seems like odd timing if it
> is. 

The behavior of telldir/closedir on FreeBSD is the same as when these
replacement functions were written (i.e. the unused telldir() linked
list nodes need to be freed in closedir()).  I'm not certain about the
rmdir issue to which the comments also refer.

Julian's recent post from the Samba people indicates they still think
the code is needed.

Joe

> 
> -- Brian
> 
> On 7/6/07, Joe Marcus Clarke <marcus_at_marcuscom.com> wrote:
>         
>         Yes, this "works" as Pascal tested for me earlier.  However,
>         if you read
>         the comments in this file there was a reason these functions
>         are
>         overridden.  The way that telldir() works can cause issues
>         when 
>         closedir() is called (e.g. network timeouts).
>         
>         In any event, I'm not sure there's a better way to do this
>         when it comes
>         to ZFS.  When doing an lseek() on a ZFS directory, the
>         internal offset
>         is set to a hash code value (as far as I can tell).  You can
>         not 
>         reliably increment this by some number, and get back to the
>         same
>         location in a given directory (in fact, you can easily get a
>         segfault by
>         doing that).
>         
>         Joe
-- 
PGP Key : http://www.marcuscom.com/pgp.asc