Re: 2.6.36 merge plans

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 23 Jul 2010 17:19:29 -0500
Steve French <smfrench@xxxxxxxxx> wrote:

> On Thu, Jul 1, 2010 at 6:52 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> > On Thu, 1 Jul 2010 16:55:58 -0500
> > Steve French <smfrench@xxxxxxxxx> 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@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux