On Fri, 3 Mar 2023 at 05:38, Steve French <smfrench@xxxxxxxxx> 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@xxxxxxxxxx> 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
