Date: Fri, 6 Jul 2007 01:19:55 -0400 From: "Brian Donnell" <bdonnell@gmail.com> To: "Joe Marcus Clarke" <marcus@marcuscom.com> Cc: current <current@freebsd.org>, "Boris S." <bst2006@dva.dyndns.org>, Pascal Hofstee <caelian@gmail.com> Subject: Re: ZFS vs Samba Debugging Results ... Need Help. Message-ID: <1c5c32890707052219p61c4abd4s7be4dd7c51a8246e@mail.gmail.com> In-Reply-To: <1183698637.55166.58.camel@shumai.marcuscom.com> References: <d8a0b7620707031331w5b0fcae2jd96cb7ff8b3f34d6@mail.gmail.com> <d8a0b7620707031359wc178fdfocf2387820fcacbf5@mail.gmail.com> <46633B27.50601@dva.dyndns.org> <1c5c32890707031732s195a97c3vd29fb46323f28fae@mail.gmail.com> <46644820.6020609@dva.dyndns.org> <1c5c32890707041057x75712a20vef9800a7ddef7a6a@mail.gmail.com> <1183674495.75595.14.camel@worf> <1c5c32890707051739t6621e2d4ude73ce5d096ea72e@mail.gmail.com> <1183698637.55166.58.camel@shumai.marcuscom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Brian On 7/6/07, Joe Marcus Clarke <marcus@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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1c5c32890707052219p61c4abd4s7be4dd7c51a8246e>