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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1335459642.9701.27.camel@lade.trondhjem.org>
Date:	Thu, 26 Apr 2012 17:00:41 +0000
From:	"Myklebust, Trond" <Trond.Myklebust@...app.com>
To:	Steve French <smfrench@...il.com>
CC:	David Howells <dhowells@...hat.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
	"linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
	"samba-technical@...ts.samba.org" <samba-technical@...ts.samba.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	"wine-devel@...ehq.org" <wine-devel@...ehq.org>,
	"kfm-devel@....org" <kfm-devel@....org>,
	"nautilus-list@...me.org" <nautilus-list@...me.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>
Subject: Re: [PATCH 0/6] Extended file stat system call

On Thu, 2012-04-26 at 11:56 -0500, Steve French wrote:
> On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond
> <Trond.Myklebust@...app.com> wrote:
> > On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote:
> >> On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells@...hat.com> wrote:
> >> > Steve French <smfrench@...il.com> wrote:
> >> >
> >> >> 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.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@...app.com
www.netapp.com