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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1335453958.9701.10.camel@lade.trondhjem.org>
Date:	Thu, 26 Apr 2012 15:25:59 +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 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?

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

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