On Fri, Jul 07, 2017 at 12:13:36PM -0400, Jeff Layton wrote:
> On Fri, 2017-07-07 at 11:51 -0400, Theodore Ts'o wrote:
> > On Fri, Jul 07, 2017 at 06:51:37AM -0400, Jeff Layton wrote:
> > >
> > > Right. That's the case today if we don't remove support for old
> > > filehandles. If we were to remov
On Fri, 2017-07-07 at 11:51 -0400, Theodore Ts'o wrote:
> On Fri, Jul 07, 2017 at 06:51:37AM -0400, Jeff Layton wrote:
> >
> > Right. That's the case today if we don't remove support for old
> > filehandles. If we were to remove them, the clients would get back
> > -ESTALE there if they tried to u
On Fri, Jul 07, 2017 at 06:51:37AM -0400, Jeff Layton wrote:
>
> Right. That's the case today if we don't remove support for old
> filehandles. If we were to remove them, the clients would get back
> -ESTALE there if they tried to use the old 2.2-style fh's that they saw
> before the upgrade.
>
>
On Wed, 2017-07-05 at 16:27 -0400, Theodore Ts'o wrote:
> On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> >
> > So, what's the probability that there are clients out there that started
> > talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
> > kernel sevente
On Thu, Jul 06, 2017 at 11:08:27AM +1000, NeilBrown wrote:
> On Wed, Jul 05 2017, J. Bruce Fields wrote:
>
> > On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> >> So, what's the probability that there are clients out there that started
> >> talking to a 2.2-based knfsd and will n
On Wed, Jul 05 2017, J. Bruce Fields wrote:
> On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
>> On Tue, Jul 04, 2017 at 09:15:34PM -0400, J. Bruce Fields wrote:
>> > On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
>> > > On Thu, Jun 29, 2017 at 02:50:22PM -0400,
On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
> On Tue, Jul 04, 2017 at 09:15:34PM -0400, J. Bruce Fields wrote:
> > On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
> > > On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> > > > On Thu, Jun 29, 201
On Wed, Jul 05, 2017 at 12:19:33PM -0700, Darrick J. Wong wrote:
>
> So, what's the probability that there are clients out there that started
> talking to a 2.2-based knfsd and will now want to talk to a modern 4.13
> kernel seventeen years later? (Do nfs handles persist across client
> restarts/
On Tue, Jul 04, 2017 at 09:15:34PM -0400, J. Bruce Fields wrote:
> On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
> > On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> > > On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > > > On Thu, Jun 29, 201
On Mon, Jul 03, 2017 at 09:04:46PM -0700, Darrick J. Wong wrote:
> On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > > Was there ever a ve
On Thu, Jun 29, 2017 at 02:50:22PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> > On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > > Was there ever a version of NFS (or more generally callers of the
> > > exportfs code) that
On Thu, Jun 29, 2017 at 02:30:53PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> > Was there ever a version of NFS (or more generally callers of the
> > exportfs code) that couldn't deal with i_generation in the file handle,
> > and therefore we
On Thu, Jun 29, 2017 at 10:25:28AM -0700, Darrick J. Wong wrote:
> Was there ever a version of NFS (or more generally callers of the
> exportfs code) that couldn't deal with i_generation in the file handle,
> and therefore we invented this generation hack to work around the loss
> of the generation
On Thu, Jun 29, 2017 at 10:35:51AM -0400, J. Bruce Fields wrote:
> On Wed, Jun 28, 2017 at 09:59:40PM -0700, Darrick J. Wong wrote:
> > AFAICT, i_generation == 0 in XFS and btrfs is just as valid as any other
> > number. There is no special casing of zero in either filesystem.
> >
> > So now, my
On Wed, Jun 28, 2017 at 09:59:40PM -0700, Darrick J. Wong wrote:
> AFAICT, i_generation == 0 in XFS and btrfs is just as valid as any other
> number. There is no special casing of zero in either filesystem.
>
> So now, my curiosity intrigued, I surveyed all the Linux filesystems
> that can export
On 6/28/17, 9:59 PM, "Darrick J. Wong" wrote:
[add linux-xfs to cc]
On Thu, Jun 29, 2017 at 04:37:14AM +, William Koh wrote:
> On 6/28/17, 7:32 PM, "Andreas Dilger" wrote:
>
> On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote:
> >
> > In fs/ext4
[add linux-xfs to cc]
On Thu, Jun 29, 2017 at 04:37:14AM +, William Koh wrote:
> On 6/28/17, 7:32 PM, "Andreas Dilger" wrote:
>
> On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote:
> >
> > In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input
> > "generation" th
On 6/28/17, 7:32 PM, "Andreas Dilger" wrote:
On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote:
>
> In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input
> "generation" that can be used to specify the generation of the inode to
> be returned. When 0 is given as i
On Jun 28, 2017, at 4:06 PM, Kyungchan Koh wrote:
>
> In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input
> "generation" that can be used to specify the generation of the inode to
> be returned. When 0 is given as input, then inodes of any generation can
> be returned. Therefore, g
On 6/28/17, 5:48 PM, "Darrick J. Wong" wrote:
On Wed, Jun 28, 2017 at 03:06:42PM -0700, Kyungchan Koh wrote:
> In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input
> "generation" that can be used to specify the generation of the inode to
> be returned. When 0 is give
On Wed, Jun 28, 2017 at 03:06:42PM -0700, Kyungchan Koh wrote:
> In fs/ext4/super.c, the function ext4_nfs_get_inode takes as input
> "generation" that can be used to specify the generation of the inode to
> be returned. When 0 is given as input, then inodes of any generation can
> be returned. The
21 matches
Mail list logo
