Message-ID: <20240916162305.vy5w5albdpuvtk2x@pali>
Date: Mon, 16 Sep 2024 18:23:05 +0200
From: Pali Rohár <pali@...nel.org>
To: Steve French <smfrench@...il.com>
Cc: Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>,
	Ronnie Sahlberg <ronniesahlberg@...il.com>,
	CIFS <linux-cifs@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/7] cifs: Fix creating of SFU fifo and socket special
 files

Now I have tested this behavior against one Windows Server 2019 instance
and it works too. So confirmed, it is the case also for 2019 version.

On Sunday 15 September 2024 19:48:24 Pali Rohár wrote:
> It works for this new 2022 version and also for old 2012 version. So my
> personal guess is yes, that it would work also for 2019 (I do not see
> reason why something would not work for version in-the-middle). If
> needed, I may try to do this test against 2019 version during next or
> another weekend.
> 
> On Sunday 15 September 2024 12:42:27 Steve French wrote:
> > Do you know if this is the case for windows server 2019
> > 
> > On Sun, Sep 15, 2024, 12:41 PM Pali Rohár <pali@...nel.org> wrote:
> > 
> > > Hello Steve,
> > >
> > > I have another argument for the empty system file as fifo over the
> > > file with "LnxFIFO" content.
> > >
> > > Now I have figured out that even the latest Windows Server 2022 version
> > > provides interoperability of FIFOs in SFU format with Windows NFS 4.1
> > > Server. So if you configure on Windows Server 2022 one share which is
> > > exported over SMB and also NFS at the same time, and over SMB you create
> > > SFU-style fifo, then Windows NFS4.1 server recognize it and properly
> > > reports nfs4type as NFS4FIFO for NFSv4.1 client.
> > >
> > > So this SFU FIFO style is not only for old clients and servers, but
> > > still relevant and useful even for latest Windows Server.
> > >
> > > And same applies for named sockets.
> > >
> > > For testing this scenario it is enough to use just trial version of
> > > latest Windows Server from:
> > > https://go.microsoft.com/fwlink/p/?linkid=2208182
> > > https://go.microsoft.com/fwlink/p/?Linkid=2195280
> > >
> > > For setting NFS4.1 and SMB share named "test" I used these cmd commands:
> > >
> > >   dism /Online /Enable-Feature /All
> > > /FeatureName:ServerForNFS-Infrastructure
> > >   md C:\test
> > >   icacls C:\test /grant Everyone:(OI)(CI)F /T
> > >   nfsshare test=C:\test -o rw unmapped=yes
> > >   net share test=C:\test /grant:Everyone,FULL
> > >
> > > (for everyone who is going to reproduce this scenario, beware that new
> > > Windows servers use by default powershell, so first launch cmd.exe then
> > > copy+paste those commands)
> > >
> > > Pali
> > >
> > > On Saturday 14 September 2024 10:17:42 Pali Rohár wrote:
> > > > On Saturday 14 September 2024 01:21:17 Steve French wrote:
> > > > > On Fri, Sep 13, 2024 at 5:42 PM Pali Rohár <pali@...nel.org> wrote:
> > > > > >
> > > > > > On Friday 13 September 2024 17:14:22 Steve French wrote:
> > > > > > > How did you find the format of the FIFO and SOCK file types?  I
> > > > > >
> > > > > > For fifo there are multiple sources on internet, but none of them is
> > > > > > normative. Everything is just what people have tried. For example
> > > this
> > > > > > old email on samba list:
> > > > > >
> > > https://lists.samba.org/archive/linux-cifs-client/2005-May/000856.html
> > > > > >
> > > > > > Format of the socket I have figured out by creating it in Interix
> > > > > > subsystem and then dumped content of the file from Win32 subsystem.
> > > > > > Then I checked that it has also same format over older MS NFS server.
> > > > > > It was easier than trying to search for some documentation (which I
> > > have
> > > > > > not found).
> > > > > >
> > > > > > > couldn't find any references to those so added two new types to
> > > allow
> > > > > > > current Linux to be able to create these (especially since they are
> > > > > > > opaque to the server and thus low risk).
> > > > > >
> > > > > > I was searching over internet again and now I have found patent
> > > > > > https://patents.google.com/patent/US20090049459 which describe
> > > symlink
> > > > > > content:
> > > > > >
> > > > > > #define NFS_SPECFILE_LNK_V1 0x014b4e4c78746e49 /* “IntxLNK” */
> > > > > >
> > > > > > But does not describe other types.
> > > > > >
> > > > > > > > +     case S_IFSOCK:
> > > > > > > > -             strscpy(pdev.type, "LnxSOCK");
> > > > > > > > +             /* SFU socket is system file with one zero byte */
> > > > > > > > +             pdev_len = 1;
> > > > > > > > +             pdev.type[0] = '\0';
> > > > > > > >               break;
> > > > > > > >       case S_IFIFO:
> > > > > > > > -             strscpy(pdev.type, "LnxFIFO");
> > > > > > > > +             /* SFU fifo is system file which is empty */
> > > > > > > > +             pdev_len = 0;
> > > > > > >
> > > > > > > My worry about the suggested change above is that it is possible
> > > that
> > > > > > > we could accidentally match to an empty file.
> > > > > >
> > > > > > I fully understand your concerns, but code in this patch is for
> > > creating
> > > > > > new fifos. Not recognizing existing fifos.
> > > > > >
> > > > > > Code for recognizing existing fifos (=empty file with system
> > > attribute)
> > > > > > was not changed and is in Linux cifs client for a very long time.
> > > > > <>
> > > > > > > We intentionally added
> > > > > > > the two new dev.type fields for these to avoid collisions with
> > > other
> > > > > > > things (and since they are Linux specific).  It seems risky to
> > > have an
> > > > > > > empty file with the system attribute marked as a FIFO, and
> > > similarly a
> > > > > > > file with one byte null as Socket.   Since this is for only the
> > > Linux
> > > > > > > client to recognize, I wanted to do something safe for those file
> > > > > > > types less likely to be confusing (ie strings for Socket and FIFO
> > > that
> > > > > > > were similar in length and format to the other special files seemed
> > > > > > > intuitive) and "LnxFIFO" and LnxSOCK" were used as the tags in the
> > > > > > > file to reduce confusion ie the tags for those two start with
> > > "Lnx" -
> > > > > > > ie "something used for Linux client" not related to the original
> > > > > > > Interix (those begin with "Intx").
> > > > > >
> > > > > > I see. Now I understand what are those types (as I have not seen them
> > > > > > before). It is somehow misleading if such "LnxFIFO" and LnxSOCK"
> > > > > > functionality is provided by SFU option, but is incompatible with MS
> > > SFU
> > > > > > and also with MS NFS server. And is also incompatible with older
> > > Linux
> > > > > > cifs clients (as they do not understand those Lnx types).
> > > > >
> > > > > I am not as worried about FIFO and SOCK type being recognized by
> > > > > older servers (since almost every use case for them would be for them
> > > > > to be seen (only) by the client - e.g. for mounts to servers that
> > > > > don't implement reparse points yet), and since they are less
> > > > > common file types I am willing to let them be unrecognized by
> > > > > old clients (we can tag them for stable if older distros don't have
> > > > > them),
> > > >
> > > > This is quite pity for old clients, to break existing interoperability.
> > > > At least I see sfu as an compatibility option either for ecosystem with
> > > > old clients, or option where server itself does not support reparse
> > > > points.
> > > >
> > > > > but I am concerned about allowing "current clients" to
> > > > > create empty files for an unusual purpose which could be
> > > > > confusing/non-intuitive.
> > > >
> > > > I understand this concern. I thought that this should not be an issue
> > > > because files are created with system attribute which is not common for
> > > > normal/ordinary usage (system attribute could be less confusing) and
> > > > also because this format, at least for fifo is used and understood by
> > > > many SW for about 30 years.
> > > >
> > > > > And since this change (at least the one to allow FIFOs to be created
> > > with "sfu"
> > > > > has been in mainline for a year and also since it uses a more
> > > intuitive tag
> > > > > ("LnxFIFO") than the empty one used by very old Windows) the only
> > > > > clients who would have created these would be already using this newer
> > > tag
> > > > > (older Linux clients couldn't have created such files - there seems
> > > more
> > > > > risk of regression with reverting the change than with continuing with
> > > > > the Linux client specific tag (at least to the one for FIFOs
> > > > > since that has been in much longer than the socket one which is recent)
> > > >
> > > > This kind of stuff is lot of times used on LTS/stable linux
> > > > distributions and new kernel to these users/admins do not have to be
> > > > delivered yet. Mostly it takes 2-3 years after release. Look for example
> > > > at RHEL cycles.
> > > >
> > > > I'm looking on this from opposite perspective. I see this an regression
> > > > in -o sfu option that after upgrading from previous LTS version to new,
> > > > -o sfu stopped to be compatible with SFU-style fifos.
> > > >
> > > > But your point is valid. But maybe it is not an issue because users
> > > > do not have updated yet to new version?
> > > >
> > > > > Will discuss with others - opinions welcome.
> > > > >
> > > > > There is an upcoming SMB3.1.1 test event coming up next week (and the
> > > annual
> > > > > Storage Developer Conference too) so I can see if others have opinions
> > > one
> > > > > way or another on whether to move to empty (or 1 byte) files for
> > > > > creating fifos/sockets
> > > >
> > > > Ok, perfect, let me know then about the result.
> > > >
> > > > > > > Note that in the long run we hope to use reparse points by default
> > > in
> > > > > > > more servers to store special files like this but there are a few
> > > > > > > cases for unusual workloads that need special file support that
> > > would
> > > > > > > have to use sfu still.  The newer reparse tags that Windows uses
> > > "WSL"
> > > > > > > have the advantage that they require fewer roundtrips to query
> > > (since
> > > > > > > the file type is in the reparse tag).
> > > > > >
> > > > > > Yes, new WSL tags seems to be better. Also SFU mount option is not
> > > > > > activated by default.
> > > > > >
> > > > > > > Also noticed an interesting problem when mounted with "sfu" -
> > > > > > > "smbgetinfo filebasicinfo /mnt/fifo1" will hang (in sys_open).  Is
> > > > > > > that expected for a FIFO?
> > > > > >
> > > > > > Reading from fifo sleep reading process until some other process
> > > write
> > > > > > data to fifo. This is how fifos are working. You can try it on local
> > > > > > filesystem (e.g. ext4 or tmpfs).
> > > > >
> > > > > makes sense - thx
> > >

Powered by blists - more mailing lists