From owner-freebsd-hackers@FreeBSD.ORG Mon Dec 17 20:45:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C310A1CA; Mon, 17 Dec 2012 20:45:34 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5AF318FC19; Mon, 17 Dec 2012 20:45:33 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAKyDz1CDaFvO/2dsb2JhbAA9CIY7uAJzgh4BAQEDAQEBASArIAsbDgoCAg0ZAikBCSYGCAcEARwEh2wGDKc6klyBIotQAgSDFYETA4hhinuCLoEcjyyDEYFGCRce X-IronPort-AV: E=Sophos;i="4.84,304,1355115600"; d="scan'208";a="5243221" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Dec 2012 15:45:26 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id D764EB3F15; Mon, 17 Dec 2012 15:45:26 -0500 (EST) Date: Mon, 17 Dec 2012 15:45:26 -0500 (EST) From: Rick Macklem To: Wojciech Puchar Message-ID: <1886761249.1455682.1355777126858.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: Subject: Re: iSCSI vs. SMB with ZFS. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-hackers@freebsd.org, Ivan Voras X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 20:45:34 -0000 Wojciech Puchar wrote: > > With a network file system (either SMB or NFS, it doesn't matter), > > you > > need to ask the server for *each* of the following situations: > > * to ask the server if a file has been changed so the client can > > use > > cached data (if the protocol supports it) > > * to ask the server if a file (or a portion of a file) has been > > locked > > by another client > > not really if there is only one user of file - then windows know this, > but > change to behaviour you described when there are more users. > > AND FINALLY the latter behaviour fails to work properly since windows > XP > (worked fine with windows 98). If you use programs that read/write > share > same files you may be sure data corruption would happen. > > you have to set > locking = yes > oplocks = no > level2 oplocks = no > > to make it work properly but even more slow!. > Btw, NFSv4 has delegations, which are essentially level2 oplocks. They can be enabled for a server if the volumes exported via NFSv4 are not being accessed locally (including Samba). For them to work, the nfscbd needs to be running on the client(s) and the clients must have IP addresses visible to the server for a callback TCP connection (no firewalls or NAT gateways). Even with delegations working, the client caching is limited to the buffer cache. I have an experimental patch that uses on-disk caching in the client for delegated files (I call it packrats), but it is not ready for production use. Now that I have the 4.1 client in place, I plan to get back to working on it. rick > > This basically means that for almost every single IO, you need to > > ask > > the server for something, which involves network traffic and > > round-trip > > delays. > Not that. The problem is that windows do not use all free memory for > caching as with local or "local" (iSCSI) disk. > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org"