On Tue, 8 Apr 2025 at 12:48, Corinna Vinschen via Cygwin <cygwin@cygwin.com> wrote: > > On Apr 3 14:28, Jeremy Drake via Cygwin wrote: > > On Wed, 2 Apr 2025, Cedric Blancher via Cygwin wrote: > > > > > On Tue, 1 Apr 2025 at 13:54, Corinna Vinschen via Cygwin > > > <cygwin@cygwin.com> wrote: > > > > No, but if we want to *better* support this driver, we need either a > > > > patch (preferred) or at least info how to distinguish in > > > > fs_info::update(*) between the MSFT driver and the NFSv4.2 driver. > > > > > > That is actually easy: Roland implemented support for > > > FileRemoteProtocolInformation in > > > https://github.com/kofemann/ms-nfs41-client/commit/e9f72b61494bebd9e26fefec2659a4511a05b0fd > > > , and the FILE_REMOTE_PROTOCOL_INFORMATION->Protocol field can be > > > used to identify the type of driver. > > > > > > Examples: > > > Windows NFSv3 driver uses WNNC_NET_MS_NFS, > > > OpenAFS uses WNNC_NET_OPENAFS, ms-nfs41-client uses > > > WNNC_NET_RDR2SAMPLE, and OpenText NFS also uses WNNC_NET_RDR2SAMPLE. > > > > > > Plan for ms-nfs42-client is to obtain an own WNNC_NET_MSNFS42CLIENT > > > tag, and also tags for DOKANY. > > > > I thought using WNNC to identify was brought up before and rejected. At > > this point, it's querying *volume* information, and has a volume handle. > > It looks like you get FileRemoteProtocolInformation by querying a *file* > > handle. I could be wrong, and maybe that handle can be queried for > > FileRemoteProtocolInformation, but it's not like that returns a unique > > identifier either. > > Actually, while the Win32 API requires a volume handle, the underlying > ntdll functions do not. They only require a handle to a file or directory > opened on the volume which is requested for volume information. > > Therefore, if possible, fs_info::update() just reuses the file handle > from the current path_conv check in progress. > > Either way, WNNC is not what we're looking for, Jeremy is entirely > on the right path here: > > > What I'm seeing of the things that come through volume information: > > FileSystemName is either NFS or DEBUG-NFS41 (the latter at least looks > > unique, if not intended for public consumption). > > fsname NFS isn't sufficient obviously. > > > The VolumeLabel is > > PnfsVolume, the VolumeSerialNumber is always 0xBABAFACE (that's got to > > suck for the "unique per-drive/share hash" mentioned in mount.cc), the > > flags are set in > > https://github.com/kofemann/ms-nfs41-client/blob/bf8d343ba2465926f3bfafa8407a69e79649cf46/daemon/nfs41_superblock.c#L173 > > This is a bug in the nfs41 driver. It should make an effort to generate > a unique serial number and/or a unique volume label. Why not generate a > hash value from the remote path? If it can't create a unique VSN, the > VSN should be set to 0. Otherwise, having the same non-0 VSN for all > mounted NFS shares will lead to confusion.
I think Tigran and Roland fixed that. > > > What stands out to me in the flags is that they include > > FILE_SUPPORTS_REMOTE_STORAGE. I'm not sure what that's supposed to > > mean, above and beyond FILE_REMOTE_DEVICE. > > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/d4bc551b-7aaf-4b4f-ba0e-3a75e7c528f0#Appendix_A_167 Also fixed by Tigran and Roland. > > Setting this flag is wrong afaics. > > Can somebody with nfs41 installed just run > > > $ /usr/lib/csih/getVolInfo <path-to-nfs-share> > > and paste the output here? As of last week's ms-nfs41-client HEAD I get this, but I added comments in <...>: /usr/lib/csih/getVolInfo.exe . Device Type : 0x07 Characteristics : 0x00000030 FILE_REMOVABLE_MEDIA : FALSE FILE_REMOTE_DEVICE : TRUE Volume Name : <nfs://derfwnb4966_ipv4:2049/> Serial Number : 2162811071 Max Filenamelength : 255 Filesystemname : <NFS> Flags : 0x084000cf FILE_CASE_SENSITIVE_SEARCH : <negotiated-with-NFSv4-server,TRUE-for-btrfs/ext4fs/xfs> FILE_CASE_PRESERVED_NAMES : <negotiated-with-NFSv4-server,TRUE-for-btrfs/ext4f/xfss> FILE_UNICODE_ON_DISK : TRUE FILE_PERSISTENT_ACLS : <negotiated-with-NFSv4-server,TRUE-for-Linux-btrfs/ext4fs+Solaris-nfsd+zfs> FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : <negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs> FILE_SUPPORTS_REPARSE_POINTS : <negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs> FILE_SUPPORTS_REMOTE_STORAGE : FALSE FILE_RETURNS_CLEANUP_RESULT_INFO : FALSE FILE_SUPPORTS_POSIX_UNLINK_RENAME : FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS : FALSE FILE_SUPPORTS_ENCRYPTION : FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE FILE_SUPPORTS_HARD_LINKS : <negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs> FILE_SUPPORTS_EXTENDED_ATTRIBUTES : <negotiated-with-NFSv4-server,TRUE-for-Solaris+Illumos-NFSv4.1-server+nfs4j-server,FALSE-for-Linux-nfsd> FILE_SUPPORTS_OPEN_BY_FILE_ID : FALSE FILE_SUPPORTS_USN_JOURNAL : FALSE FILE_SUPPORTS_INTEGRITY_STREAMS : FALSE FILE_SUPPORTS_BLOCK_REFCOUNTING : <negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs//xfs,FALSE-for-ext4fs> FILE_SUPPORTS_SPARSE_VDL : FALSE FILE_DAX_VOLUME : FALSE FILE_SUPPORTS_GHOSTING : FALSE SectorInfoFlags : 0x07 SSINFO_FLAGS_NO_SEEK_PENALTY : TRUE SSINFO_FLAGS_TRIM_ENABLED : <negotiated-with-NFSv4-server,TRUE-for-NFSv4.2-server-with-btrfs/ext4fs/xfs> As you can see with NFSv4.1/NFSv4.2 the features set returned by GetVolumeInformationByHandleW() is very flexible and depends on the capabilities of the filesystem exported by nfsd. For example FILE_CASE_SENSITIVE_SEARCH+FILE_CASE_PRESERVED_NAMES are both TRUE for normal Linux+Solaris filesystems, but FALSE if FAT32 is exported by the NFS server. Same for FILE_SUPPORTS_BLOCK_REFCOUNTING, it depends on NFSv4.2 protocol support in the server, and whether the exported filesystem supported file/block cloning - btrfs, bcachefs, xfs, zfs support this, ext4 and fat32 do not. Hardlinks are not supported by FAT32, so the NFSv4.2 client will not return TRUE in that case. And that all applies to FILE_SUPPORTS_EXTENDED_ATTRIBUTES, FILE_SUPPORTS_SPARSE_FILES and so on, too. But you also get this kind of flexibility with SMB3.2, but much worse: Server sets the defaults, and the admin on the client can override this. > > > MS NFS only seems to set > > FILE_CASE_PRESERVED_NAMES (2), so the existing flag song-and-dance could > > probably be extended to tell the difference here. > > > > They're also always setting > > SSINFO_FLAGS_ALIGNED_DEVICE|SSINFO_FLAGS_PARTITION_ALIGNED_ON_DEVIVE| > > SSINFO_FLAGS_NO_SEEK_PENALTY. > > Could be helpful to distinguish between both NFS versions, but I don't > trust Windows to set the flags if the server is a Windows machine. > Or something. SSINFO_FLAGS_NO_SEEK_PENALTY is tied to FILE_SUPPORTS_SPARSE_FILES for ms-nfs41-client Ced -- Cedric Blancher <cedric.blanc...@gmail.com> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
