On 12/7/24 9:36 PM, Takeshi Nishimura wrote:
On Sat, Dec 7, 2024 at 6:49 PM Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
On 12/7/24 12:14 PM, Takeshi Nishimura wrote:
On Fri, Dec 6, 2024 at 10:55 PM Roland Mainz <roland.mainz@xxxxxxxxxxx> wrote:
Hi!
----
Below (also attached as
"0001-mount.nfs4-Add-support-for-nfs-URLs_v2.patch" and available at
https://nrubsig.kpaste.net/e8c5cb) is version 2 of the patch which
adds support for nfs://-URLs in mount.nfs4, as alternative to the
traditional hostname:/path+-o port=<tcp-port> notation.
* Main advantages are:
- Single-line notation with the familiar URL syntax, which includes
hostname, path *AND* TCP port number (last one is a common generator
of *PAIN* with ISPs) in ONE string
- Support for non-ASCII mount points, e.g. paths with CJKV (Chinese,
Japanese, ...) characters, which is typically a big problem if you try
to transfer such mount point information across email/chat/clipboard
etc., which tends to mangle such characters to death (e.g.
transliteration, adding of ZWSP or just '?').
- Server
mkdir '/nfsroot11/アーカイブ'
- Convert path at https://www.urlencoder.org/
'/nfsroot11/アーカイブ' ---->
'/nfsroot11/%E3%82%A2%E3%83%BC%E3%82%AB%E3%82%A4%E3%83%96'
- Client
mount.nfs -o rw
'nfs://133.1.138.101//nfsroot11//%E3%82%A2%E3%83%BC%E3%82%AB%E3%82%A4%E3%83%96'
/mnt
Works - (◕‿◕) - 素晴らしい
@Roland Mainz Thank you!!
- URL parameters are supported, providing support for future extensions
* Notes:
- Similar support for nfs://-URLs exists in other NFSv4.*
implementations, including Illumos, Windows ms-nfs41-client,
sahlberg/libnfs, ...
- This is NOT about WebNFS, this is only to use an URL representation
to make the life of admins a LOT easier
- Only absolute paths are supported
- This feature will not be provided for NFSv3
NFSv3 does not do Unicode, so this is not going to work anyway
There are two purposes for adding an NFS URL mechanism to mount.nfs:
one is having a common way to express a server hostname and export
path; the other is to add support for percent escape.
We still should consider NFS URLs on NFSv3 with the code points
that NFSv3 servers can support.
What "code points"? NFSv3 does not use UTF-8. NFSv2/v3 use sequences
of bytes and a length, and the filename encoding is up to the client
and server to set.
Despite the i18n discussion in the NFSv4 standards, that is essentially
what is implemented in Linux for all NFS versions.
There is no protocol to figure that out, and the choices are plentiful, e.g.
az_AZ.KOI8-C
be_BY.CP1251
bg_BG.CP1251
bg_BG.KOI8-R
fa_IR.ISIRI-3342
he_IL.CP1255
hi_IN.ISCII-DEV
iu_CA.NUNACOM-8
ja_JP.eucJP
ja_JP.JIS7
ja_JP.SJIS
ka_GE.GEORGIAN-ACADEMY
ka_GE.GEORGIAN-PS
ko_KR.eucKR
lo_LA.IBM-CP1133
lo_LA.MULELAO-1
mk_MK.CP1251
ru_RU.CP1251
ru_RU.KOI8-R
ru_UA.CP1251
ru_UA.KOI8-U
ta_IN.TSCII-0
tg_TJ.KOI8-C
th_TH.TIS620
tt_RU.KOI8-C
tt_RU.TATAR-CYR
uk_UA.CP1251
uk_UA.KOI8-U
ur_PK.CP1256
vi_VN.TCVN
vi_VN.VISCII
yi_US.CP1255
zh_CN.eucCN
zh_CN.gb18030
zh_CN.gb2312
zh_CN.gbk
zh_HK.big5
zh_HK.big5hkscs
zh_TW.big5
zh_TW.eucTW
...
So, which one will you choose? You do have to do that manually, by
hand, at mountall time you just don't have that info.
And it's even WORSE than you can imagine - many of the Asian encodings
are INCOMPATIBLE (!!!) to Unicode, because the morons at the Unicode
consortium did the cursed "Han unifications". This "unification" maps
similar looking characters from different languages(!!) into a single
Unicode code point.
For CJV users it feels like forcing Americans to spell "New York" as
"NEW Y卐RK", because of course uppercase and lowercase looks similar,
and "O" can be substituted with the similar looking "卐". That's what
the Unicode consortium did to my language.
So, you just lose data if you try to do a mapping of older GBK, JIS,
... encodings to Unicode. For filenames encoded in Unicode codepoints,
e.g. a URL (which uses UTF-8) there is NO WAY BACK to GBK, JIS ...
imagine sort of lossy JPEG compression for filenames, you never get
the original back.
So forget that concept that URLs and NFSv3 will play along - that only
works for English speaking users on a whiteboard, but not for Asian
users in real life.
If there is a strong technical justification for not supporting NFSv3,
then it needs to have been spelled out in the patch description. It
wasn't. So I asked "why not NFSv3?"
I'm not sure other implementations of NFS make this careful distinction.
I don't see that in libnfs, for instance; their URLs appear to support
NFSv3.
We'll have to do some research.
For NFSv4 it works, because the protocol uses - for better or worse -
UTF-8 for everything, and fortunately doesn't even attempt to do case
folding.
So using an URL for NFSv4/4.1/4.2 is safe.
--
Chuck Lever
