[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070503154428.GA32713@infradead.org>
Date: Thu, 3 May 2007 16:44:28 +0100
From: Christoph Hellwig <hch@...radead.org>
To: Steve French <smfrench@...il.com>
Cc: linux-kernel@...r.kernel.org,
Gerald Carter <coffeedude.jerry@...il.com>,
Christoph Hellwig <hch@...radead.org>,
linux-cifs-client@...ts.samba.org, simo <idra@...ba.org>
Subject: Re: [linux-cifs-client] Re: SMB2 file system - should it be a distinct module
On Thu, May 03, 2007 at 10:35:41AM -0500, Steve French wrote:
> If SMB2 protocol support were coded as a distinct module, the smb2.ko
> would need to load cifs.ko to complete session setup in many cases
> (presumably when mounting to NetApp, EMC, most older Windows servers
> and some Samba servers - at least for a few years).
Umm, no. If the user tries mount -t smb2 it would try only that and
if it can't support the server it would fail. Similar for mount -t cifs
if the server only supports modern dialects, which AFAIK none does.
If you feel fancy add autoprobing to mount, similar to how we do
automatic testing of superblocks for disk filesystems.
> In any case SMB2 would be considered experimental (for a Linux client)
> for quite some time, so there is no hurry to decide until there is
> feedback from users. I am pleased that SMB2 does clean up the
> protocol header format - and it should be easier to code in some ways
> since there are so few operations to support/optimize (and almost all
> are handlebased), but it is way to early to tell which is better (as
> far as I know, no one has even proved whether SMB2 is faster than CIFS
> or Vista to Vista mounts).
Beeing handle based means it actually starts to get useable for Unix
based client, so even if the protocol is not inherently faster the
client side implementation will be a lot faster at least on big
systems because the expensive path generation will go away.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists