From: Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
To: Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] mount.cifs: remove smb2 multicall binary code
Date: Sat, 12 May 2012 16:12:46 -0400 [thread overview]
Message-ID: <20120512161246.40eecb56@corrin.poochiereds.net> (raw)
In-Reply-To: <CAH2r5msRufn6WRjhoFuFtZTD=7v-7_9K9jG6+KMQxLeGConwnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 11 May 2012 21:43:57 -0500
Steve French <smfrench@gmail.com> wrote:
> This may be fine but we need to ask the obvious question ...
>
> Are we sure that we don't ever want a distinct fstype (cifs vs. smb2)
> in the long run?
>
> It does seem strange that smb2 and cifs would be the same fstype. For a while
> fstab supported nfs4 as an fstype (as distinct from nfs (nfs3)) cifs
> and smb2 are
> quite a bit different.
>
> Certainly calling smb3 or smb2 as cifs should work - but I have the feeling
> that smb3 will in the long run be better known as a name (than cifs) so
> we will have to provide synonyms (mount.smb3 could basically would
> be mount.cifs but pass vers=3)
>
I see no value in a separate fstype here. It just adds confusion and
extra code that we'll need to maintain and also doesn't add anything
from a user interface perspective -- quite the contrary, really...
/bin/mount already knows to choose a "cifs" fstype whenever it sees a
device string that looks like a UNC. A different fstype breaks that
heuristic. So, the only way /sbin/mount.smb2 or /sbin/mount.smb3 would
ever be called is if you were to mount with a specific command like:
# mount -t smb2 //server/share...
...and I don't consider that any easier from a user perspective than
using "-o vers="
Also, if you ever want to do autonegotiation, then a separate fstype is
really a non-starter. Once you've called mount() then your fstype is
decided and that's that...
The fact that nfs4 was a separate fstype from nfs is pretty well
considered a mistake now. We're moving as quickly as we can to
deprecate the use of '-t nfs4' in the mainline implementation, fwiw.
In short, just say no to a new fstype unless it's unavoidable... ;)
- --
Jeff Layton <jlayton@samba.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iQIcBAEBAgAGBQJPrsREAAoJEAAOaEEZVoIVSG4QAIluoTeSjdgOSfVsXKqjETuF
E/ZtaPLTkRJK3xy1iKRBvF6Mk6I6EjzM2DZ+bt/xpYxczYnnT+UuFGWTL+N/9cjL
CGiZKSDYtDrDxo+JZW7sEXp9Ds19jU1ZSODlXlu2maRoXJ1VbkZoEvExaBHAo+00
GwHz1De9SO7uSSCnLDSvf6g/z6NrfUe5rFCyhNSuOsVlY2tn/h2wiPnY+2j9ZbEM
h9ZgoEtiZrW6JgRliCZ1HiMfrnR+llhsGGbR/hCUx6ZebHBYsS6tMTI1N6ZBs0Pj
5gwc9bo5sdzYHG9FF1xP5MMPWvnx3D+38BP0f4BV4R/0mGkqYbk9z5DP/Looqfeh
rHfjs8GRIukmarduQskBkYz+3AoSf8zdZCpXbIBsFv50SYOLvj1abVGEvWlplmSJ
XJwHjdPaiKj9iKUXQ6w2xSEcTd4pwi52gW9HTbct/xwytNZLkUkY38N4ToLgXzh0
uRXITWR4JGMveWqjWwcEOhNWfiZtNODBZqgRaiAxNraf1MeD8MoaCnvRB2BEm6qt
gu1eNbG1LzXg7AfZxl6Zfz1GMoccHwu2LFCMYUmbCHzzuprSKagrzQAhnfMEWsje
77wTxnlg3DwKwC5cdo/S0sGzU0v8jE5evfswX0Qt40lqOXNKvpcfTLjdDDGQr376
4YJdb37f/YOfoSGWx4Ci
=y4SA
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2012-05-12 20:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-12 1:00 [PATCH] mount.cifs: remove smb2 multicall binary code Jeff Layton
[not found] ` <1336784436-9176-1-git-send-email-jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>
2012-05-12 2:43 ` Steve French
[not found] ` <CAH2r5msRufn6WRjhoFuFtZTD=7v-7_9K9jG6+KMQxLeGConwnQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-05-12 20:12 ` Jeff Layton [this message]
2012-05-17 10:48 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120512161246.40eecb56@corrin.poochiereds.net \
--to=jlayton-eunubhrolfbytjvyw6ydsg@public.gmane.org \
--cc=linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox