Re: 2.6.36 merge plans

Re: 2.6.36 merge plans

[Steve French]

On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Thu, 1 Jul 2010 16:55:58 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> For   cifs: use CreationTime like an i_generation field
>> Seems like a good idea, but what happens if server is unix one without
>> birth time, eg samba with no xattr support and changes creation time
>> (ie uses last mtime or some such) frequently - e.g. on every write?
>> Would that break your aprroach?
>>
>
> Aye, there's the rub. This makes a ton of sense for windows where we
> can count on a valid create time. Samba servers may be problematic here,
> but with most of them we'll be using unix extensions and you don't get
> create times there anyway. The problem may be samba or other
> non-windows servers without unix extensions that fake up create times.
>
> We could consider a mount option or something to ignore create times,
> but how to document when it should be used? IMO, fake create times are
> really a server bug. Do we hobble servers where this is done correctly?

Jeff,
I merged the other patches from your tree, but wanted to think more about
http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=commit;h=e5b7e004ed0ccdcf5fd3b1b0aff2a1a45023912b
ie the CreationTime i_generation patch and what happens to servers
which don't have creation time - presumably e.g. most Samba servers
on Linux can't get to creation time.  Any additional thoughts on this?

-- 
Thanks,

Steve

Re: 2.6.36 merge plans

[Jeff Layton]

On Fri, 23 Jul 2010 17:19:29 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Thu, 1 Jul 2010 16:55:58 -0500
> > Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> For   cifs: use CreationTime like an i_generation field
> >> Seems like a good idea, but what happens if server is unix one without
> >> birth time, eg samba with no xattr support and changes creation time
> >> (ie uses last mtime or some such) frequently - e.g. on every write?
> >> Would that break your aprroach?
> >>
> >
> > Aye, there's the rub. This makes a ton of sense for windows where we
> > can count on a valid create time. Samba servers may be problematic here,
> > but with most of them we'll be using unix extensions and you don't get
> > create times there anyway. The problem may be samba or other
> > non-windows servers without unix extensions that fake up create times.
> >
> > We could consider a mount option or something to ignore create times,
> > but how to document when it should be used? IMO, fake create times are
> > really a server bug. Do we hobble servers where this is done correctly?
> 
> Jeff,
> I merged the other patches from your tree, but wanted to think more about
> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=commit;h=e5b7e004ed0ccdcf5fd3b1b0aff2a1a45023912b
> ie the CreationTime i_generation patch and what happens to servers
> which don't have creation time - presumably e.g. most Samba servers
> on Linux can't get to creation time.  Any additional thoughts on this?
> 

Yeah, the createtime from samba is bogus. But...we'll typically be
using unix extensions when talking to those servers and the POSIX
qpathinfo call doesn't return create times. This patch has no effect on
that case.

The only questionable case is talking to samba or another server that
fakes up create times, *and* unix extensions aren't in use. In that
case, you'll essentially end up getting a new inode from a cifs_iget
call whenever the createtime on the file has changed.

Samba (oddly enough) uses the ctime of the file as the createtime. So,
basically that situation will be that you'd end up with a new inode
from cifs_iget if the metadata of the file has changed.

The situation is very similar to the noserverino case. The main

1) the inode number wouldn't seem to change when you got the new inode
in this situation

2) you'd sometimes match an existing inode, providing its metadata
hasn't changed since the last time we checked it

I think the impact is minimal. I also think it's preferable to
unnecessarily spawn a new inode rather than match an existing one that
shouldn't be matched.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: 2.6.36 merge plans

[Jeff Layton]

On Fri, 23 Jul 2010 17:19:29 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Thu, 1 Jul 2010 16:55:58 -0500
> > Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> For   cifs: use CreationTime like an i_generation field
> >> Seems like a good idea, but what happens if server is unix one without
> >> birth time, eg samba with no xattr support and changes creation time
> >> (ie uses last mtime or some such) frequently - e.g. on every write?
> >> Would that break your aprroach?
> >>
> >
> > Aye, there's the rub. This makes a ton of sense for windows where we
> > can count on a valid create time. Samba servers may be problematic here,
> > but with most of them we'll be using unix extensions and you don't get
> > create times there anyway. The problem may be samba or other
> > non-windows servers without unix extensions that fake up create times.
> >
> > We could consider a mount option or something to ignore create times,
> > but how to document when it should be used? IMO, fake create times are
> > really a server bug. Do we hobble servers where this is done correctly?
> 
> Jeff,
> I merged the other patches from your tree, but wanted to think more about
> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=commit;h=e5b7e004ed0ccdcf5fd3b1b0aff2a1a45023912b
> ie the CreationTime i_generation patch and what happens to servers
> which don't have creation time - presumably e.g. most Samba servers
> on Linux can't get to creation time.  Any additional thoughts on this?
> 

Hi Steve,

Looks like Linus released 2.6.35 yesterday. There's still a patch in my
tree that's unmerged as of yet and that I'd like to see go into 2.6.36:

cifs: reduce false positives with inode aliasing serverino autodisable

...any reason that you haven't merged it yet?

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Re: 2.6.36 merge plans

[Steve French]

On Mon, Aug 2, 2010 at 12:46 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Fri, 23 Jul 2010 17:19:29 -0500
> Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > On Thu, 1 Jul 2010 16:55:58 -0500
>> > Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >> For   cifs: use CreationTime like an i_generation field
>> >> Seems like a good idea, but what happens if server is unix one without
>> >> birth time, eg samba with no xattr support and changes creation time
>> >> (ie uses last mtime or some such) frequently - e.g. on every write?
>> >> Would that break your aprroach?
>> >>
>> >
>> > Aye, there's the rub. This makes a ton of sense for windows where we
>> > can count on a valid create time. Samba servers may be problematic here,
>> > but with most of them we'll be using unix extensions and you don't get
>> > create times there anyway. The problem may be samba or other
>> > non-windows servers without unix extensions that fake up create times.
>> >
>> > We could consider a mount option or something to ignore create times,
>> > but how to document when it should be used? IMO, fake create times are
>> > really a server bug. Do we hobble servers where this is done correctly?
>>
>> Jeff,
>> I merged the other patches from your tree, but wanted to think more about
>> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=commit;h=e5b7e004ed0ccdcf5fd3b1b0aff2a1a45023912b
>> ie the CreationTime i_generation patch and what happens to servers
>> which don't have creation time - presumably e.g. most Samba servers
>> on Linux can't get to creation time.  Any additional thoughts on this?
>>
>
> Hi Steve,
>
> Looks like Linus released 2.6.35 yesterday. There's still a patch in my
> tree that's unmerged as of yet and that I'd like to see go into 2.6.36:
>
> cifs: reduce false positives with inode aliasing serverino autodisable
>
> ...any reason that you haven't merged it yet?

I had no problem with the last patch in your tree, but wanted
to test the one before it (the creation time patch) before merging,
and thought it would be easier to merge them in order since
they hit at least one file in common.

Backing out the one patch I wanted to test more with Samba (the
creation time one)
I made a big merge request today to clear the 27 patches queued up already,
and expect to merge your last two and Dave's DNS one and probably
Shirish's (if they can be tested/reviewed more) this week.


-- 
Thanks,

Steve

Re: 2.6.36 merge plans

[Steve French]

On Fri, Jul 23, 2010 at 6:13 PM, Jeff Layton <jlayton@redhat.com> wrote:
> On Fri, 23 Jul 2010 17:19:29 -0500
> Steve French <smfrench@gmail.com> wrote:
>
>> On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton@redhat.com> wrote:
>> > On Thu, 1 Jul 2010 16:55:58 -0500
>> > Steve French <smfrench@gmail.com> wrote:
>> >> For   cifs: use CreationTime like an i_generation field
>> >> Seems like a good idea, but what happens if server is unix one without
>> >> birth time, eg samba with no xattr support and changes creation time
>> >> (ie uses last mtime or some such) frequently - e.g. on every write?
>> >> Would that break your aprroach?
>> >>
>> >
>> > Aye, there's the rub. This makes a ton of sense for windows where we
>> > can count on a valid create time. Samba servers may be problematic here,
>> > but with most of them we'll be using unix extensions and you don't get
>> > create times there anyway. The problem may be samba or other
>> > non-windows servers without unix extensions that fake up create times.
>> >
>> > We could consider a mount option or something to ignore create times,
>> > but how to document when it should be used? IMO, fake create times are
>> > really a server bug. Do we hobble servers where this is done correctly?
>>
>> Jeff,
>> I merged the other patches from your tree, but wanted to think more about
>> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=commit;h=e5b7e004ed0ccdcf5fd3b1b0aff2a1a45023912b
>> ie the CreationTime i_generation patch and what happens to servers
>> which don't have creation time - presumably e.g. most Samba servers
>> on Linux can't get to creation time.  Any additional thoughts on this?
>>
>
> Yeah, the createtime from samba is bogus. But...we'll typically be
> using unix extensions when talking to those servers and the POSIX
> qpathinfo call doesn't return create times. This patch has no effect on
> that case.
>
> The only questionable case is talking to samba or another server that
> fakes up create times, *and* unix extensions aren't in use. In that
> case, you'll essentially end up getting a new inode from a cifs_iget
> call whenever the createtime on the file has changed.
>
> Samba (oddly enough) uses the ctime of the file as the createtime. So,
> basically that situation will be that you'd end up with a new inode
> from cifs_iget if the metadata of the file has changed.
>
> The situation is very similar to the noserverino case. The main
>
> 1) the inode number wouldn't seem to change when you got the new inode
> in this situation
>
> 2) you'd sometimes match an existing inode, providing its metadata
> hasn't changed since the last time we checked it
>
> I think the impact is minimal. I also think it's preferable to
> unnecessarily spawn a new inode rather than match an existing one that
> shouldn't be matched.

Jeff,
I think all of your cifs patches are in cifs-2.6.git now - except for
the creation time as i_generation patch which AFAIK is not in your
tree anymore - is that changing?  Any additional feedback on that or
testing with older Samba?



-- 
Thanks,

Steve
--
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

Re: 2.6.36 merge plans

[Jeff Layton]

On Tue, 3 Aug 2010 23:31:14 -0500
Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Fri, Jul 23, 2010 at 6:13 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > On Fri, 23 Jul 2010 17:19:29 -0500
> > Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> >> > On Thu, 1 Jul 2010 16:55:58 -0500
> >> > Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >> >> For   cifs: use CreationTime like an i_generation field
> >> >> Seems like a good idea, but what happens if server is unix one without
> >> >> birth time, eg samba with no xattr support and changes creation time
> >> >> (ie uses last mtime or some such) frequently - e.g. on every write?
> >> >> Would that break your aprroach?
> >> >>
> >> >
> >> > Aye, there's the rub. This makes a ton of sense for windows where we
> >> > can count on a valid create time. Samba servers may be problematic here,
> >> > but with most of them we'll be using unix extensions and you don't get
> >> > create times there anyway. The problem may be samba or other
> >> > non-windows servers without unix extensions that fake up create times.
> >> >
> >> > We could consider a mount option or something to ignore create times,
> >> > but how to document when it should be used? IMO, fake create times are
> >> > really a server bug. Do we hobble servers where this is done correctly?
> >>
> >> Jeff,
> >> I merged the other patches from your tree, but wanted to think more about
> >> http://git.kernel.org/?p=linux/kernel/git/jlayton/linux.git;a=commit;h=e5b7e004ed0ccdcf5fd3b1b0aff2a1a45023912b
> >> ie the CreationTime i_generation patch and what happens to servers
> >> which don't have creation time - presumably e.g. most Samba servers
> >> on Linux can't get to creation time.  Any additional thoughts on this?
> >>
> >
> > Yeah, the createtime from samba is bogus. But...we'll typically be
> > using unix extensions when talking to those servers and the POSIX
> > qpathinfo call doesn't return create times. This patch has no effect on
> > that case.
> >
> > The only questionable case is talking to samba or another server that
> > fakes up create times, *and* unix extensions aren't in use. In that
> > case, you'll essentially end up getting a new inode from a cifs_iget
> > call whenever the createtime on the file has changed.
> >
> > Samba (oddly enough) uses the ctime of the file as the createtime. So,
> > basically that situation will be that you'd end up with a new inode
> > from cifs_iget if the metadata of the file has changed.
> >
> > The situation is very similar to the noserverino case. The main
> >
> > 1) the inode number wouldn't seem to change when you got the new inode
> > in this situation
> >
> > 2) you'd sometimes match an existing inode, providing its metadata
> > hasn't changed since the last time we checked it
> >
> > I think the impact is minimal. I also think it's preferable to
> > unnecessarily spawn a new inode rather than match an existing one that
> > shouldn't be matched.
> 
> Jeff,
> I think all of your cifs patches are in cifs-2.6.git now - except for
> the creation time as i_generation patch which AFAIK is not in your
> tree anymore - is that changing?  Any additional feedback on that or
> testing with older Samba?
> 
> 
> 

Huh, my mistake. Not sure what happened but it did disappear from my
tree. It's there now. I've not seen problems with testing against older
samba with it, but if there were any they're likely to be what I've
outlined above.

-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>