On 3/2/2023 2:23 PM, Steve French 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.
Well yeah, it can't be a random assignment, and the fileid is only
unique within the scope of a volumeid. Blindly using the server's
fileid as a client inode without checking for a volume crossing is
a client protocol violation, right?
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.
