Date: Thu, 25 May 2000 09:21:14 +0100 From: Brian Somers <brian@Awfulhak.org> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: Arun Sharma <adsharma@sharmas.dhs.org>, hackers@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: file creation times ? Message-ID: <200005250821.JAA00580@hak.lan.Awfulhak.org> In-Reply-To: Message from Peter Jeremy <peter.jeremy@alcatel.com.au> of "Thu, 25 May 2000 13:15:26 %2B1000." <00May25.131527est.115222@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[.....]
> 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 <inode>
/<timestamp><filename> 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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005250821.JAA00580>