From: Andreas Dilger <adilger@dilger.ca> To: David Howells <dhowells@redhat.com> Cc: Steve French <smfrench@gmail.com>, "dhowells@redhat.com" <dhowells@redhat.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>, "samba-technical@lists.samba.org" <samba-technical@lists.samba.org>, "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>, "wine-devel@winehq.org" <wine-devel@winehq.org>, "kfm-devel@kde.org" <kfm-devel@kde.org>, "nautilus-list@gnome.org" <nautilus-list@gnome.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org> Subject: Re: [PATCH 0/6] Extended file stat system call Date: Thu, 26 Apr 2012 19:29:27 -0500 [thread overview] Message-ID: <3F302713-B675-4BAA-B2B7-235E03C5975F@dilger.ca> (raw) In-Reply-To: <24787.1335455535@redhat.com> On 2012-04-26, at 10:52, David Howells <dhowells@redhat.com> wrote: > Steve French <smfrench@gmail.com> wrote: >> >> 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. I'd agree. Why fake up an inode number if the application doesn't care? Most apps don't actually use the inode. The only uses I know for the inode number in userspace are backup, CIFS/NFS servers, and "ls -li" . > 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. It is a bit strange that the kernel would return a flag that was not requested, but not fatal. > 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Dilger <adilger@dilger.ca> Cc: Steve French <smfrench@gmail.com>, "dhowells@redhat.com" <dhowells@redhat.com>, "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>, "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>, "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>, "samba-technical@lists.samba.org" <samba-technical@lists.samba.org>, "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>, "wine-devel@winehq.org" <wine-devel@winehq.org>, "kfm-devel@kde.org" <kfm-devel@kde.org>, "nautilus-list@gnome.org" <nautilus-list@gnome.org>, "linux-api@vger.kernel.org" <linux-api@vger.kernel.org>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org> Subject: Re: [PATCH 0/6] Extended file stat system call Date: Thu, 26 Apr 2012 19:29:27 -0500 [thread overview] Message-ID: <3F302713-B675-4BAA-B2B7-235E03C5975F@dilger.ca> (raw) In-Reply-To: <24787.1335455535@redhat.com> On 2012-04-26, at 10:52, David Howells <dhowells@redhat.com> wrote: > Steve French <smfrench@gmail.com> wrote: >> >> 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. I'd agree. Why fake up an inode number if the application doesn't care? Most apps don't actually use the inode. The only uses I know for the inode number in userspace are backup, CIFS/NFS servers, and "ls -li" . > 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. It is a bit strange that the kernel would return a flag that was not requested, but not fatal. > 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-04-27 0:29 UTC|newest] Thread overview: 144+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-19 14:05 [PATCH 0/6] Extended file stat system call David Howells 2012-04-19 14:05 ` David Howells 2012-04-19 14:06 ` [PATCH 3/6] xstat: AFS: Return extended attributes David Howells 2012-04-19 14:06 ` [PATCH 4/6] xstat: NFS: " David Howells [not found] ` <20120419140653.17272.95035.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2012-04-19 14:35 ` Myklebust, Trond 2012-04-19 14:35 ` Myklebust, Trond 2012-04-26 13:52 ` David Howells 2012-04-19 14:07 ` [PATCH 5/6] xstat: CIFS: " David Howells [not found] ` <20120419140706.17272.72290.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2012-04-19 15:19 ` Steve French 2012-04-19 15:19 ` Steve French 2012-04-19 16:32 ` [PATCH 0/6] Extended file stat system call Roland McGrath 2012-04-19 21:51 ` Paul Eggert 2012-04-19 23:05 ` Roland McGrath 2012-04-26 14:16 ` David Howells [not found] ` <20173.1335449760-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 18:22 ` Roland McGrath 2012-04-26 18:22 ` Roland McGrath [not found] ` <4F9088D6.9020203-764C0pRuGfqVc3sceRu5cw@public.gmane.org> 2012-04-26 14:04 ` David Howells 2012-04-26 14:04 ` David Howells [not found] ` <19638.1335449047-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 18:24 ` Roland McGrath 2012-04-26 18:24 ` Roland McGrath 2012-04-19 23:29 ` Andreas Dilger 2012-04-26 13:54 ` David Howells [not found] ` <19184.1335448455-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 18:25 ` Roland McGrath 2012-04-26 18:25 ` Roland McGrath 2012-04-27 23:54 ` Paul Eggert [not found] ` <20120426182524.E5ADF2C0EC-j1d2VQoJOwwHfwO+Tb3JRVaTQe2KTcn/@public.gmane.org> 2012-04-26 21:54 ` David Howells 2012-04-26 21:54 ` David Howells [not found] ` <9931.1335477281-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 22:02 ` Roland McGrath 2012-04-26 22:02 ` Roland McGrath 2012-04-26 22:21 ` Nix 2012-04-26 14:25 ` David Howells 2012-04-26 14:54 ` Steve French [not found] ` <CAH2r5mv1Lijdwk5zsQwYJr4Etb6fhrRyNXm-iFCQX+HecboGrQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-26 15:25 ` Myklebust, Trond 2012-04-26 15:25 ` Myklebust, Trond 2012-04-26 16:56 ` Steve French 2012-04-26 16:56 ` Steve French [not found] ` <CAH2r5mt5af-_hxBRKK72iD5Gr99bo91ec78Rov8EGVEx8=21mA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-26 17:00 ` Myklebust, Trond 2012-04-26 17:00 ` Myklebust, Trond 2012-04-26 17:03 ` Steve French 2012-04-26 17:03 ` Steve French [not found] ` <CAH2r5mvmCfLrxRHje6Wx5X84zxPEHwRMUJGsjvWBujMu7w841w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-26 17:06 ` Myklebust, Trond 2012-04-26 17:06 ` Myklebust, Trond [not found] ` <1335460011.9701.30.camel-SyLVLa/KEI9HwK5hSS5vWB2eb7JE58TQ@public.gmane.org> 2012-04-26 17:09 ` Steve French 2012-04-26 17:09 ` Steve French [not found] ` <CAH2r5muXk+frkFz9X523Ny=RMwJGeqOPH75G1ToNa5QoMo5SkQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-26 17:10 ` Steve French 2012-04-26 17:10 ` Steve French 2012-04-26 21:57 ` David Howells 2012-04-26 21:57 ` David Howells [not found] ` <10104.1335477476-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 22:05 ` Roland McGrath 2012-04-26 22:05 ` Roland McGrath [not found] ` <20120426220552.D98D62C0D3-j1d2VQoJOwwHfwO+Tb3JRVaTQe2KTcn/@public.gmane.org> 2012-04-27 0:33 ` Myklebust, Trond 2012-04-27 0:33 ` Myklebust, Trond 2012-04-27 0:30 ` Myklebust, Trond 2012-04-27 0:30 ` Myklebust, Trond 2012-04-26 15:52 ` David Howells 2012-04-27 0:29 ` Andreas Dilger [this message] 2012-04-27 0:29 ` Andreas Dilger [not found] ` <3F302713-B675-4BAA-B2B7-235E03C5975F-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> 2012-04-27 9:19 ` David Howells 2012-04-27 9:19 ` David Howells [not found] ` <20120419140558.17272.74360.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2012-04-19 14:06 ` [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available David Howells 2012-04-19 14:06 ` David Howells 2012-04-19 23:36 ` Andreas Dilger [not found] ` <20120419140612.17272.57774.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2012-04-24 21:29 ` J. Bruce Fields 2012-04-24 21:29 ` J. Bruce Fields [not found] ` <20120424212911.GA26073-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-04-24 22:08 ` Steve French 2012-04-24 22:08 ` Steve French 2012-04-25 14:44 ` Andreas Dilger 2012-04-25 14:44 ` Andreas Dilger 2012-04-26 13:45 ` David Howells [not found] ` <18765.1335447954-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 14:28 ` J. Bruce Fields 2012-04-26 14:28 ` J. Bruce Fields 2012-04-26 17:06 ` Steve French 2012-04-26 17:06 ` Steve French 2012-04-26 13:32 ` David Howells [not found] ` <18195.1335447156-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-27 0:51 ` Dave Chinner 2012-04-27 0:51 ` Dave Chinner 2012-04-27 3:11 ` Andreas Dilger 2012-04-27 3:11 ` Andreas Dilger 2012-04-26 13:40 ` David Howells [not found] ` <18533.1335447617-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-26 14:23 ` J. Bruce Fields 2012-04-26 14:23 ` J. Bruce Fields 2012-04-30 16:27 ` Ben Hutchings 2012-04-30 20:15 ` David Howells 2012-04-30 20:30 ` J. Bruce Fields 2012-04-30 23:31 ` Ben Hutchings 2012-04-19 14:06 ` [PATCH 2/6] xstat: Ext4: Return extended attributes David Howells 2012-04-19 14:06 ` David Howells [not found] ` <20120419140625.17272.23303.stgit-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org> 2012-04-19 16:03 ` Steve French 2012-04-19 16:03 ` Steve French 2012-04-26 13:47 ` David Howells 2012-04-26 17:00 ` Steve French 2012-04-26 17:00 ` Steve French 2012-04-19 14:07 ` [PATCH 6/6] xstat: eCryptFS: " David Howells 2012-04-19 14:07 ` David Howells 2012-04-19 17:11 ` [PATCH 0/6] Extended file stat system call Steve French 2012-04-19 17:11 ` Steve French 2012-04-27 1:06 ` Dave Chinner 2012-04-27 1:06 ` Dave Chinner 2012-04-27 3:22 ` Andreas Dilger [not found] ` <ED5B8F1B-6C99-4516-85FA-A767E94B635F-m1MBpc4rdrD3fQ9qLvQP4Q@public.gmane.org> 2012-04-28 0:38 ` Dave Chinner 2012-04-28 0:38 ` Dave Chinner 2012-04-28 0:54 ` Steve French 2012-05-08 20:19 ` Extended file stat: Splitting file- and fs-specific info? David Howells 2012-05-08 20:19 ` David Howells 2012-05-08 21:13 ` Myklebust, Trond 2012-05-08 21:13 ` Myklebust, Trond [not found] ` <16281.1336508382-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-05-09 0:24 ` Dave Chinner 2012-05-09 0:24 ` Dave Chinner 2012-05-09 1:09 ` J. Bruce Fields 2012-05-09 1:09 ` J. Bruce Fields 2012-05-09 4:25 ` Dave Chinner 2012-05-09 11:14 ` J. Bruce Fields 2012-05-09 11:14 ` J. Bruce Fields 2012-05-09 1:16 ` Andreas Dilger 2012-05-09 1:16 ` Andreas Dilger 2012-05-10 9:23 ` David Howells [not found] ` <14477.1336641794-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-05-10 16:05 ` Andreas Dilger 2012-05-10 16:05 ` Andreas Dilger 2012-05-10 17:10 ` Roland McGrath 2012-05-10 17:10 ` Roland McGrath 2012-05-11 8:54 ` Andreas Dilger 2012-05-09 9:21 ` David Howells 2012-05-09 9:21 ` David Howells [not found] ` <20170.1336555274-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-05-09 11:19 ` Christoph Hellwig 2012-05-09 11:19 ` Christoph Hellwig [not found] ` <20120509111958.GA11345-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2012-05-09 11:55 ` Bernd Schubert 2012-05-09 11:55 ` Bernd Schubert [not found] ` <4FAA5B24.1020306-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org> 2012-05-09 12:05 ` Christoph Hellwig 2012-05-09 12:05 ` Christoph Hellwig [not found] ` <20120509120544.GA17535-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> 2012-05-09 12:25 ` Bernd Schubert 2012-05-09 12:25 ` Bernd Schubert 2012-05-09 13:51 ` Andreas Dilger 2012-05-09 14:12 ` Bernd Schubert 2012-05-10 9:14 ` David Howells 2012-05-10 9:14 ` David Howells 2012-04-27 9:39 ` [PATCH 0/6] Extended file stat system call David Howells [not found] ` <4111.1335519545-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2012-04-27 13:13 ` Dave Chinner 2012-04-27 13:13 ` Dave Chinner 2012-04-27 15:10 ` J. Bruce Fields [not found] ` <20120427151057.GA16580-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> 2012-04-27 16:32 ` Steve French 2012-04-27 16:32 ` Steve French 2012-04-27 19:31 ` Andreas Dilger 2012-04-28 0:58 ` Dave Chinner 2012-05-10 9:51 ` David Howells
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3F302713-B675-4BAA-B2B7-235E03C5975F@dilger.ca \ --to=adilger@dilger.ca \ --cc=dhowells@redhat.com \ --cc=kfm-devel@kde.org \ --cc=libc-alpha@sourceware.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-cifs@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-nfs@vger.kernel.org \ --cc=nautilus-list@gnome.org \ --cc=samba-technical@lists.samba.org \ --cc=smfrench@gmail.com \ --cc=wine-devel@winehq.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.