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
| ||
|
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
Powered by blists - more mailing lists