From: Andi Kleen <ak@muc.de>
To: Andreas Gruenbacher <agruen@suse.de>
Cc: Alex Tomas <alex@clusterfs.com>,
Andrew Tridgell <tridge@samba.org>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Ext3 nanosecond timestamps in big inodes
Date: Sun, 16 Jan 2005 05:37:34 +0100 [thread overview]
Message-ID: <m1acravvjl.fsf@muc.de> (raw)
In-Reply-To: <200501142216.12726.agruen@suse.de> (Andreas Gruenbacher's message of "Fri, 14 Jan 2005 22:16:12 +0100")
Andreas Gruenbacher <agruen@suse.de> writes:
> 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?
>
> 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.
Looks good. Just two suggestions:
- Provide an mount option to turn it off because there may be
performance regressions in some workload because inodes will be
flushed more often.
[I actually considered doing this generally at the VFS level
when doing the s_time_gran patch, but it needed some more changes
that I didn't want to do at that time. Doing it in the FS as
interim solution would be fine too]
- Use the 2 bits for additionals years right now on 64bit
hosts. No need to keep the y2038 issue around longer than necessary.
-Andi
next prev parent reply other threads:[~2005-01-16 4:38 UTC|newest]
Thread overview: 5+ 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 4:37 ` Andi Kleen [this message]
2005-01-15 14:41 ` Andreas Gruenbacher
2005-01-16 5:46 ` Andreas Dilger
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=m1acravvjl.fsf@muc.de \
--to=ak@muc.de \
--cc=agruen@suse.de \
--cc=alex@clusterfs.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.