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: <CAH2r5muXk+frkFz9X523Ny=RMwJGeqOPH75G1ToNa5QoMo5SkQ@mail.gmail.com>
Date:	Thu, 26 Apr 2012 12:09:38 -0500
From:	Steve French <smfrench@...il.com>
To:	"Myklebust, Trond" <Trond.Myklebust@...app.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, Apr 26, 2012 at 12:06 PM, Myklebust, Trond
<Trond.Myklebust@...app.com> wrote:
> On Thu, 2012-04-26 at 12:03 -0500, Steve French wrote:
>> On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond
>> <Trond.Myklebust@...app.com> wrote:
>> > 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.
>>
>> 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-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html