-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 11 May 2012 21:43:57 -0500
Steve French <[email protected]> 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 <[email protected]>
-----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-----
