linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Alex Tomas <alex@clusterfs.com>,
	Andrew Tridgell <tridge@samba.org>
Subject: Re: [RFC] Ext3 nanosecond timestamps in big inodes
Date: Sat, 15 Jan 2005 22:46:04 -0700	[thread overview]
Message-ID: <20050116054604.GI22715@schnapps.adilger.int> (raw)
In-Reply-To: <200501142216.12726.agruen@suse.de>

[-- Attachment #1: Type: text/plain, Size: 3360 bytes --]

On Jan 14, 2005  22:16 +0100, Andreas Gruenbacher wrote:
> this is a spin-off of an old patch by Alex Tomas <alex@clusterfs.com>:
> Alex originally had nanosecond timestamps in his original patch; here is
> a rejuvenated version. Please tell me what you think. Alex also added a
> create timestamp in his original patch. Do we actually need that?

I think the create timestamp can't hurt things and might be useful in some
cases (e.g. CIFS could use this for exporting, and Lustre will also).  It
would also be useful for some disk "forensics" (term used loosely) unlike
the ctime.  I haven't ever been very keen on nsecond atimes, but it can't
kill us (atime is already flushed at most 1/sec I think).

> Nanoseconds consume 30 bits in the 32-bit fields. The remaining two bits 
> currently are zeroed out implicitly. We could later use them remaining two 
> bits for years beyond 2038.

My thought has always been to use, say, 24 bits for "nseconds>>6" and 8 bits
for "seconds<<32" or something close to this (a few bits either way) to give
us more range on the high end.  In the past we talked of usecond timestamps
(which would have only been 20 bits, leaving 12 bits for seconds msb),
but the kernel ended up using nseconds for the internal timestamps.

> @@ -2501,6 +2501,14 @@ void ext3_read_inode(struct inode * inod
> +		if (ei->i_extra_isize >= 2*sizeof(__le16) + 3*sizeof(__le32)) {
> +			inode->i_atime.tv_nsec =
> +				le32_to_cpu(raw_inode->i_atime_nsec);
> +			inode->i_ctime.tv_nsec =
> +				le32_to_cpu(raw_inode->i_ctime_nsec);
> +			inode->i_mtime.tv_nsec =
> +				le32_to_cpu(raw_inode->i_mtime_nsec);
> +		}

You may as well put a macro here to convert from the raw timestamp
(probably shouldn't just be called "nsec" if we are also encoding more
info there, maybe msb_and_ns?) so we can mask (and shift) as necessary.

> @@ -2638,8 +2646,17 @@ static int ext3_do_update_inode(handle_t
> -	if (EXT3_INODE_SIZE(inode->i_sb) > EXT3_GOOD_OLD_INODE_SIZE)
> +	if (ei->i_extra_isize) {

I don't think this is right.  This means we would only ever store nsec
timestamps if there was already other data in the large inode.  Since
writing that part of the inode is free (we will be writing a full sector
anyways), no reason not to save it.

>  		raw_inode->i_extra_isize = cpu_to_le16(ei->i_extra_isize);
> +		if (ei->i_extra_isize > 2*sizeof(__le16) + 3*sizeof(__le32)) {
> +			raw_inode->i_atime_nsec =
> +				cpu_to_le32(inode->i_atime.tv_nsec);
> +			raw_inode->i_ctime_nsec =
> +				cpu_to_le32(inode->i_ctime.tv_nsec);
> +			raw_inode->i_mtime_nsec =
> +				cpu_to_le32(inode->i_mtime.tv_nsec);
> +		}
> +	}

Macro here also to convert from nsec to the ext3-internal "msb_and_ns" format.

> +static inline struct timespec ext3_current_time(struct inode *inode)
> +{
> +	return (inode->i_sb->s_time_gran == 1) ?
> +	       CURRENT_TIME : CURRENT_TIME_SEC;
> +}

If "s_time_gran" (I haven't seen this before but it doesn't appear to
be a part of your patch) had some useful meaning we could use it to e.g.
shift the nsec part of the timestamps as Andy requested so as not to make
the timestamps change too often.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://members.shaw.ca/adilger/             http://members.shaw.ca/golinux/


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-01-16 21:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-14 21:16 [RFC] Ext3 nanosecond timestamps in big inodes Andreas Gruenbacher
2005-01-16  5:46 ` Andreas Dilger [this message]
2005-01-17  9:49   ` Anton Altaparmakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050116054604.GI22715@schnapps.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=agruen@suse.de \
    --cc=alex@clusterfs.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tridge@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).