Re: [PATCH 0/6] Extended file stat system call

On Thu, Apr 26, 2012 at 12:06 PM, Myklebust, Trond
[off-list ref] wrote:

On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:

quoted

On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
[off-list ref] wrote:

quoted

On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:

quoted

On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
[off-list ref] wrote:

quoted

On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:

quoted

On Thu, Apr 26, 2012 at 9:25 AM, David Howells [off-list ref] wrote:

quoted

Steve French [off-list ref] wrote:

quoted

Would it be better to make the stable vs volatile inode number an attribute
of the volume  or something returned by the proposed xstat?

I'm not sure what you mean by a stable vs a volatile inode number.

Both NFS and CIFS (and SMB2) can return inode numbers or equivalent
unique identifier, but in the case of CIFS some old servers don't support the
calls which return inode numbers (or don't return them for all file system
types, Windows FAT?) so in these cases cifs has to create inode
numbers on the fly
on the client.   inode numbers created on the client are not "stable" they
can change on unmount/remount (which can cause problems for backup
applications).

Similarly NFSv4 does not require that servers always return stable inode numbers
(that will never change) and introduced a concept of "volatile file handle."
We have run into this in two cases (there are probably more) -
Specialized NFS servers
for HPC which deal with lots of transient inodes, and second those for servers
which base there inode number on path (Windows NFS?).  See
http://docs.oracle.com/cd/E19082-01/819-1634/rfsrefer-137/index.html
or the NFSv4 RFC.

Basically the question is whether it is worth reporting a flag on the
call which returns
the inode number to indicate that the inode number is "stable" (would not change
on reboot or reconnection) or "volatile."    Since the majority of NFS
and SMB2 servers
can return stable inode numbers, I don't feel strongly about the need
for an indicator
of "stable" vs. "volatile" but I mention it because backup and
migration applications
mention this (if inode numbers are volatile, they may have to check
for hardlinks differently
for example)

I don't understand. If the filesystem doesn't support real inode
numbers, then why report them at all? What use would an application have
for an inode number that can't be used to identify hard linked files?

Well ... you have to have an inode number on the Linux client side even if
the server doesn't report them (or has a bug and reports duplicates).
If you can't tell hardlinked files apart fix the server (but in the
cases where the file systems has this problem the server doesn't usually
support hardlinks either).

If the server's file system internal structures don't support real inode
numbers (such as FAT or a ramdisk) then it either has to make them
up based on something like path name or some other attribute of the
file on disk.

Servers like NetApp is where this gets interesting - for cifs e.g. level 1009
query file info is used to query_file_internal_info (the inode number) but
what if the server can not report inode numbers (due to a bug) in
all cases.

Right, but none of this explains why we need to report these bogus inode
numbers to the application in the xstat() reply.

the question is whether the application (backup) would need to know
that the inode numbers are bogus and from my conversations with
guys writing backup software it seems that such data is useful to them.

You are still not explaining why they need to know the values at all? If
the values are bogus, then don't return them, and don't set the flag
that says they are being returned.

I don't know, but assumed it was because it was an easy way
to index them since the inode numbers even if they "change"
on remount, are still unique.



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html