Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759097Ab0GVQ72 (ORCPT ); Thu, 22 Jul 2010 12:59:28 -0400 Received: from mail-out1.uio.no ([129.240.10.57]:49941 "EHLO mail-out1.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758310Ab0GVQ7W (ORCPT ); Thu, 22 Jul 2010 12:59:22 -0400 Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6] From: Trond Myklebust To: Linus Torvalds Cc: Jeremy Allison , Volker.Lendecke@sernet.de, David Howells , Jan Engelhardt , linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org In-Reply-To: References: <20100715021709.5544.64506.stgit@warthog.procyon.org.uk> <20100715021712.5544.44845.stgit@warthog.procyon.org.uk> <30448.1279800887@redhat.com> <20100722162712.GB10352@jeremy-laptop> Content-Type: text/plain; charset="UTF-8" Date: Thu, 22 Jul 2010 12:58:50 -0400 Message-ID: <1279817930.3621.14.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 (2.30.2-1.fc13) Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 1 sum rcpts/h 13 sum msgs/h 1 total rcpts 645 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B75C99ED25F15AE964EF808A2B4CC1E78D940BFB X-UiO-SPAM-Test: remote_host: 68.40.206.115 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 274 max/h 6 blacklist 0 greylist 0 ratelimit 0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3432 Lines: 73 On Thu, 2010-07-22 at 09:40 -0700, Linus Torvalds wrote: > On Thu, Jul 22, 2010 at 9:27 AM, Jeremy Allison wrote: > > On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote: > >> Tell me why we shouldn't just do this right? > > > > No, ctime isn't the same as Windows "create time". > > Umm. What kind of reading problems do you guys have? > > I know effin well that ctime isn't the same as Windows create time. > THAT WAS MY POINT. > > But the fact is, th Unix ctime semantics are insane and largely > useless. There's a damn good reason almost nobody uses ctime under > unix. > > So what I'm suggesting is that we have a flag - either per-process or > per-mount - that just says "use windows semantics for ctime". > > And yes, I'm very aware that the "c" in ctime doesn't stand for > "create". But anybody who points that out is - once more - totally > missing the point. My point is that we have three timestamps, and > windows wants three timestamps (somebody claims that NTFS has four > timestamps, but the Windows file time access functions certainly only > shows three times, so any potential extra on-disk times have no > relevance because they are invisible to pretty much everybody). We can > have unix semantics for mtime/atime/ctime, or we can have windows > semantics for those three values. > > So let's say that we introduce a mount flag that says > "ctime=winctime", which basically just sets a flag that instead of > changing ctime on chmod/chown/etc, it just changes mtime instead (or, > as mentioned, we could make it a process flag instead). > > Let's face it, Unix semantics are not sacred. Especially not > something like ctime, which is pretty damn useless. If you're a samba > server, why not just say "let's do ctime the way windows does creation > times", and let it be at that? > > I personally think that Unix ctime is insane. There is no real reason > why "write()" should change mtime, but "chmod" changes ctime. It was > just a random decision way back when, and it's clearly not what samba > wants, and it's equally clearly not what even most _unix_ people want > (just google for "ctime" and "creation time", and watch the confusion > - exactly because unix semantics are simply _random_ and odd semantics > in this area) > > I would not be at all surprised if it turns out that people might want > to really turn ctime into creation time (with the mount flag or > whatever) even if they are _not_ running samba. > > An added issue is that most filesystems simply don't have more than > three times (and some obviously have not even that, but that's true in > Windows too). So re-using ctime actually means that this scheme would > work a whole lot better than some crazy xstat() interface that doesn't > support common filesystems anyway. That would make it impossible to export the filesystem with NFSv2 and v3. They do rely on ctime checking for certain operations (e.g. deciding when to invalidate access and acl caches). NFSv4 needs this too if the filesystem has no dedicated change attribute. Still, I suppose the market for exporting the same filesystem with both NFS and Samba is limited... Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/