From owner-freebsd-hackers Thu May 25 2: 3:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.139.170]) by hub.freebsd.org (Postfix) with ESMTP id E103637B527 for ; Thu, 25 May 2000 02:03:22 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (hak.nat.Awfulhak.org [172.31.0.12]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id KAA78840; Thu, 25 May 2000 10:03:15 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id JAA00580; Thu, 25 May 2000 09:21:14 +0100 (BST) (envelope-from brian@Awfulhak.org) Message-Id: <200005250821.JAA00580@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: Peter Jeremy Cc: Arun Sharma , hackers@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: file creation times ? In-Reply-To: Message from Peter Jeremy of "Thu, 25 May 2000 13:15:26 +1000." <00May25.131527est.115222@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 May 2000 09:21:14 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [.....] > Adding a creation timestamp would add 4 or 8 bytes of metadata > to each file, as well as requiring additional code (and CPU time) > to manage it. A 6th Edition inode was 32 bytes (and only stored > access and modify times). A FreeBSD inode is already 4 times as > big. It's necessary to strike a balance between storing every > possible piece of information about a file and the amount of > space/time used to store/manage this metadata. I'm not advocating adding a creation time, but had it been done when the ufs/ffs was designed I think it would be a nice thing - *but* I suspect the correct place to store it is in the directory itself along with the inode number and file name. > A modification timestamp is essential to support incremental backups. > Splitting it into separate data and metadata timestamps meets POLA > (users generally want 'modification' to mean that the content changed, > not that the file was renamed). Access timestamps are important for > filespace management (knowing what files aren't used and can therefore > be archived or deleted). Of course access timestamps are usually useless anyway as most (?!!) people will back up their system from time to time.... OOPS ! I never realised before now - dump *doesn't* update the access time. This is *really* excellent :-) Scratch this comment about access times being useless ! > As far as I'm concerned, you still haven't demonstrated any real > need or justification for a creation timestamp. That said, > there's nothing stopping you adding a creation timestamp to the > UFS and providing patches. This should be trivial if added to the directory itself and should be fully ``option''d in the kernel :-) I think it would be useful to some. Of course doing it in the directory would make it a pretty much one-way option, so if the work was done, it would be most appropriate to have the capability included as some sort of newfs/tunefs option. If the format of the directory with this option enabled became / then the code could allow non-creation-time filesystems to be mounted as creation-time filesystems and could just add the timestamp to new files (by asserting that the existence of the '/' means there's a timestamp next). > Peter -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message