April 2012 - Wine-Devel - list.winehq.org

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

by Steve French

On Thu, Apr 26, 2012 at 12:00 PM, Myklebust, Trond <Trond.Myklebust(a)netapp.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(a)netapp.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(a)redhat.com> wrote: >> >> > Steve French <smfrench(a)gmail.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. -- Thanks, Steve

April 26, 2012

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

by Myklebust, Trond

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(a)netapp.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(a)redhat.com> wrote: > >> > Steve French <smfrench(a)gmail.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(a)netapp.com www.netapp.com

April 26, 2012

Re: [PATCH 2/6] xstat: Ext4: Return extended attributes

by Steve French

On Thu, Apr 26, 2012 at 8:47 AM, David Howells <dhowells(a)redhat.com> wrote: > Steve French <smfrench(a)gmail.com> wrote: > >> This patch reminds me of a question on time stamps - how can an >> application query the time granularity ie sb_s_time_gran for a mount >> (e.g. 1 second for some file systems, 100 nanoseconds for cifs/smb2, 1 >> nanosecond for others etc.) > > Ummm... In what context? With the proposed xstat() interface it will be > provided. great (although I thought it would be "stat -f" property). -- Thanks, Steve

April 26, 2012

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

by Steve French

On Thu, Apr 26, 2012 at 10:25 AM, Myklebust, Trond <Trond.Myklebust(a)netapp.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(a)redhat.com> wrote: >> > Steve French <smfrench(a)gmail.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. -- Thanks, Steve

April 26, 2012

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

by David Howells

Steve French <smfrench(a)gmail.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). In the volatile case you'd probably want to unset XSTAT_INO in st_mask as the inode number is a local fabrication. However, since there is a remote file ID, we could add an XSTAT_INFO_FILE_ID flag to indicate there's a standard xattr holding this. On CIFS this could be the servername + pathname, on NFS this could be the server address + FH on AFS the cell+volID+FID+uniquifier for example. That's independent of xstat, however, and wouldn't be returned as it's a blob that could be quite large. I presume in some cases, there is not a unique file ID that persists across rename. > Similarly NFSv4 does not require that servers always return stable inode > numbers (that will never change) and introduced a concept of "volatile file > handle." Can I presume the inode number cannot be considered stable if the NFS4 FH is non-volatile? Furthermore, can I presume NFS2/3 inode numbers are supposed to be stable? > 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) It may be that unsetting XSTAT_INO if you've fabricated the inode number locally is sufficient. > >> > Handle remote filesystems being offline and indicate this with > >> > XSTAT_INFO_OFFLINE. > >> > >> You already have support for an indicator for offline files (HSM), Which indicator is this? Or do you mean XSTAT_INFO_OFFLINE? > >> would XSTAT_INFO_OFFLINE be intended for the case > >> where the network session to the server is disconnected > >> (and in which you case the application does not want to reconnect)? > > > > Hmmm... Interesting question. Both NTFS and CIFS have an offline > > attribute (which is where I originally got this from) - but should I have a > > separate indicator to indicate the client can't access a server over a > > network (ie. we've gone to disconnected operation on this file)? > > E.g. should there be a XSTAT_INFO_DISCONNECTED too? > > my reaction is no, since it adds complexity. If you do a stat on a > disconnected volume (where the network is temporarily down) reconnection will > be attempted. If reconnection fails then the xstat will either fail or be > retried forever depending on the value of "hard" vs. "soft" mount flag. I was thinking of how to handle disconnected operation, where you can't just sit there and churn waiting for the server to come back or give an error. On the other hand, as long as there's some spare space in the struct, we can deal with that later when we actually start to implement D/O. David

April 26, 2012

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

by Myklebust, Trond

On Thu, 2012-04-26 at 09:54 -0500, Steve French wrote: > On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: > > Steve French <smfrench(a)gmail.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(a)netapp.com www.netapp.com

April 26, 2012

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

by Steve French

On Thu, Apr 26, 2012 at 9:25 AM, David Howells <dhowells(a)redhat.com> wrote: > Steve French <smfrench(a)gmail.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) >> > Should things like the Windows Archive, Hidden and System bits be handled >> > through IOC flags, perhaps expanded to 64-bits? >> >> Today I export these through an psuedo-xattr in cifs.ko, I am curious how >> NTFS and FAT export these on linux. > > NTFS: Not at all. > > FAT: The hidden bit causes the filename to get a dot prepended (and nothing > else is noted). > >> > Autofs, ntfs, btrfs, ... >> >> Given the overlap in optional attributes between the network >> protocol and local NTFS (and ReFS and to a lesser extent FAT) >> I would expect cifs.ko and the ntfs implementations >> info to map pretty closely. > > Yep. I wasn't going to do more filesystems till we'd finished arguing about > the basic arrangement of things in struct xstat. makes sense >> > Handle remote filesystems being offline and indicate this with >> > XSTAT_INFO_OFFLINE. >> >> You already have support for an indicator for offline files (HSM), > > HSM HSM is the more general case of two tiered data (disk vs. tape) en.wikipedia.org/wiki/Hierarchical_storage_management in the simplest case on "disk" (fast) vs. moved to tape (slow to retrieve) >> would XSTAT_INFO_OFFLINE be intended for the case >> where the network session to the server is disconnected >> (and in which you case the application does not want to reconnect)? > > Hmmm... Interesting question. Both NTFS and CIFS have an offline attribute > (which is where I originally got this from) - but should I have a separate > indicator to indicate the client can't access a server over a network > (ie. we've gone to disconnected operation on this file)? E.g. should there be > a XSTAT_INFO_DISCONNECTED too? my reaction is no, since it adds complexity. If you do a stat on a disconnected volume (where the network is temporarily down) reconnection will be attempted. If reconnection fails then the xstat will either fail or be retried forever depending on the value of "hard" vs. "soft" mount flag. -- Thanks, Steve

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by J. Bruce Fields

On Thu, Apr 26, 2012 at 02:45:54PM +0100, David Howells wrote: > Steve French <smfrench(a)gmail.com> wrote: > > > I also would prefer that we simply treat the time granularity as part > > of the superblock (mounted volume) ie returned on fstat rather than on > > every stat of the filesystem. For cifs mounts we could conceivably > > have different time granularity (1 or 2 second) on mounts to old > > servers rather than 100 nanoseconds. > > The question is whether you want to have to do a statfs in addition to a stat? > I suppose you can potentially cache the statfs based on device number. > > That said, there are cases where caching filesystem-level info based on i_dev > doesn't work. OpenAFS springs to mind as that only has one superblock and > thus one set of device numbers, but keeps all the inodes for all the different > volumes it may have mounted there. > > I don't know whether this would be a problem for CIFS too - say on a windows > server you fabricate P:, for example, by joining together several filesystems > (with junctions?). How does this appear on a Linux client when it steps from > one filesystem to another within a mounted share? In the NFS case we do try to preserve filesystem boundaries as well as we can--the protocol has an fsid field and the client creates a new mount each time it sees it change. And the protocol defines time_delta as a per-filesystem attribute (though, somewhat hilariously, there's also a per-filesystem "homogeneous" attribute that a server can clear to indicate the per-filesystem attributes might actually vary within the filesystem.) --b.

April 26, 2012

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

by David Howells

Steve French <smfrench(a)gmail.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. > > Should things like the Windows Archive, Hidden and System bits be handled > > through IOC flags, perhaps expanded to 64-bits? > > Today I export these through an psuedo-xattr in cifs.ko, I am curious how > NTFS and FAT export these on linux. NTFS: Not at all. FAT: The hidden bit causes the filename to get a dot prepended (and nothing else is noted). > > Autofs, ntfs, btrfs, ... > > Given the overlap in optional attributes between the network > protocol and local NTFS (and ReFS and to a lesser extent FAT) > I would expect cifs.ko and the ntfs implementations > info to map pretty closely. Yep. I wasn't going to do more filesystems till we'd finished arguing about the basic arrangement of things in struct xstat. > > Handle remote filesystems being offline and indicate this with > > XSTAT_INFO_OFFLINE. > > You already have support for an indicator for offline files (HSM), HSM? > would XSTAT_INFO_OFFLINE be intended for the case > where the network session to the server is disconnected > (and in which you case the application does not want to reconnect)? Hmmm... Interesting question. Both NTFS and CIFS have an offline attribute (which is where I originally got this from) - but should I have a separate indicator to indicate the client can't access a server over a network (ie. we've gone to disconnected operation on this file)? E.g. should there be a XSTAT_INFO_DISCONNECTED too? David

April 26, 2012

Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

by J. Bruce Fields

On Thu, Apr 26, 2012 at 02:40:17PM +0100, David Howells wrote: > J. Bruce Fields <bfields(a)fieldses.org> wrote: > > > > (11) Include granularity fields in the time data to indicate the > > > granularity of each of the times (NFSv4 time_delta) [Steve French]. > > > > It looks like you're including this with *each* time? But surely > > there's no filesystem with different granularity (say) for ctime than > > for mtime. > > I put it in each time struct to use up the hole there. I could, I suppose, > split tv_sec from tv_nsec to get rid of the holes and then put the granularity > separately. That means that someone who wanted both the tv_sec and tv_nsec > would have to fish them out separately, but that's probably okay. > > I could even make the granularity bigger then, to allow for the possibility of > having a granularity >4s, but I don't know of anywhere that requires a gran >2. > > > Also, nfsd will want only one time_delta, not one for each time. > > time_delta? Is that the same as granularity? Right, sorry, that's just the NFS word for the same thing. So my whine here is just that most callers only want to know one number and we're giving them three. Whatever, they can just pick one. It feels a little ugly, but feel free to ignore my nitpicking.... (Though as Steve French asked: could we add this to statfs (or something similar) instead?) > > > Note also we need to document carefully what this means: I think it > > should be the granularity that the filesystem is capable of > > representing, but people are sometimes surprised to find out that the > > actual time source is usually more coarse-grained than that. > > Yeah, but the latter is something you may not be able to determine, and may > indeed change over time (say someone updates the server kernel to one with a > more fine-grained software clock). Also, for a network fs, it may depend on > the client that happened to set that time last. Yep, agreed, the granularity should be what the filesystem can store, we should just make sure that statement makes it into any eventual man pages or other documentation, since it does seem to surprise people. --b.

April 26, 2012