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-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
