On Fri, Jul 23, 2010 at 6:13 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > 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, 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-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
