Re: Nested NTFS volumes within Windows SMB share may result in inode collisions in linux client

[ronnie sahlberg <ronniesahlberg@gmail.com>]

On Fri, 3 Mar 2023 at 05:38, Steve French <smfrench@gmail.com> wrote:
>
> > Why isn't this behavior simply the default?
>
> Without persisted inode numbers (UniqueId) it would cause problems
> with hardlinks (ie mounting with noserverino).  We could try a trick
> of hashing them with the volume id if we could detect the transition
> to a different volume (as original thread was discussing) -
> fortunately in Linux you have to walk a path component by component so
> might be possible to spot these more easily.

Just hashing it with something does not make the problem go away, it
would just make it
more unpredictable to trigger or reproduce  but the very serious issue
with data loss that Tom ponted out still remains.

Maybe a solution is to NOT traverse across these volume transitions at
all in the client and maybe users should be forced to
explicitely mount these different volumes clientside, exactly like how
NFSv3 does and requires clients to deal with this situation.

But yes, it is an extremely serious bug that will cause data loss when
it triggers for files we write to.


>
> On Thu, Mar 2, 2023 at 1:19 PM Tom Talpey <tom@talpey.com> wrote:
> >
> > On 3/1/2023 8:49 PM, Steve French wrote:
> > > I would expect when the inode collision is noted that
> > > "cifs_autodisable_serverino()" will get called in the Linux client and
> > > you should see: "Autodisabling the user of server inode numbers on
> > > ..."
> > > "Consider mounting with noserverino to silence this message"
> >
> > Why isn't this behavior simply the default? It's going to be
> > data corruption (sev 1 issue) if the inode number is the same
> > for two different fileid's, so this seems entirely backwards.
> >
> > Also, the words "to silence this message" really don't convey
> > the severity of the situation.
> >
> > Tom.
>
>
>
> --
> Thanks,
>
> Steve