From: Amir Goldstein <amir73il@gmail.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
Eric Sandeen <sandeen@sandeen.net>
Subject: Re: [PATCH 07/11] xfs: kill struct xfs_ictimestamp
Date: Thu, 27 Aug 2020 11:17:34 +0300 [thread overview]
Message-ID: <CAOQ4uxiXNaboUgCs6A5zjfnMpmb8+=m+TaZ6fKj0-5sknie3Ag@mail.gmail.com> (raw)
In-Reply-To: <20200827065114.GA17534@infradead.org>
On Thu, Aug 27, 2020 at 9:51 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> > + */
> > +static inline xfs_ictimestamp_t
> > +xfs_inode_to_log_dinode_ts(
> > + const struct timespec64 tv)
> > +{
> > + uint64_t t;
> > +
> > +#ifdef __LITTLE_ENDIAN
> > + t = ((uint64_t)tv.tv_nsec << 32) | ((uint64_t)tv.tv_sec & 0xffffffff);
> > +#elif __BIG_ENDIAN
> > + t = ((int64_t)tv.tv_sec << 32) | ((uint64_t)tv.tv_nsec & 0xffffffff);
> > +#else
> > +# error System is neither little nor big endian?
> > +#endif
> > + return t;
>
> Looking at this I wonder if we should just keep the struct and cast
> to it locally in the conversion functions, as that should take
> care of everything. Or just keep the union from the previous version,
> sorry..
Looking at this my eyes pop out.
I realize that maintaining on-disk format of the log is challenging,
so if there is no other technical solution that will be easier for humans
to review and maintain going forward, I will step back and let others
review this code.
But it bears the question: do we have to support replaying on BE a
log that was recorded on LE? Especially with so little BE machines
around these days, this sounds like over design to me.
Wouldn't it be better just to keep a bit in the log if it is LE or BE and refuse
to replay it on the wrong architecture?
Sure, we need to support whatever we supported up to now, but "bigtime"
can require a new incompat log feature "host order" (or something).
Anyway, I am probably mumbling utter garbage, do feel free to ignore
or set me straight.
Thanks,
Amir.
next prev parent reply other threads:[~2020-08-27 8:17 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-26 22:04 [PATCH v4 00/11] xfs: widen timestamps to deal with y2038 Darrick J. Wong
2020-08-26 22:05 ` [PATCH 01/11] xfs: explicitly define inode timestamp range Darrick J. Wong
2020-08-27 6:42 ` Christoph Hellwig
2020-08-28 4:08 ` Allison Collins
2020-08-26 22:05 ` [PATCH 02/11] xfs: refactor quota expiration timer modification Darrick J. Wong
2020-08-27 6:43 ` Christoph Hellwig
2020-08-28 4:08 ` Allison Collins
2020-08-26 22:05 ` [PATCH 03/11] xfs: refactor default quota grace period setting code Darrick J. Wong
2020-08-27 6:44 ` Christoph Hellwig
2020-08-28 4:08 ` Allison Collins
2020-08-26 22:05 ` [PATCH 04/11] xfs: refactor quota timestamp coding Darrick J. Wong
2020-08-27 6:44 ` Christoph Hellwig
2020-08-28 4:08 ` Allison Collins
2020-08-26 22:05 ` [PATCH 05/11] xfs: move xfs_log_dinode_to_disk to the log recovery code Darrick J. Wong
2020-08-27 6:45 ` Christoph Hellwig
2020-08-28 4:08 ` Allison Collins
2020-08-26 22:05 ` [PATCH 06/11] xfs: kill struct xfs_timestamp Darrick J. Wong
2020-08-28 4:08 ` Allison Collins
2020-08-26 22:05 ` [PATCH 07/11] xfs: kill struct xfs_ictimestamp Darrick J. Wong
2020-08-27 6:51 ` Christoph Hellwig
2020-08-27 8:17 ` Amir Goldstein [this message]
2020-08-27 8:18 ` Christoph Hellwig
2020-08-27 8:56 ` Amir Goldstein
2020-08-27 15:31 ` Darrick J. Wong
2020-08-26 22:05 ` [PATCH 08/11] xfs: widen ondisk inode timestamps to deal with y2038+ Darrick J. Wong
2020-08-27 6:58 ` Christoph Hellwig
2020-08-27 15:38 ` Darrick J. Wong
2020-08-26 22:05 ` [PATCH 09/11] xfs: widen ondisk quota expiration timestamps to handle y2038+ Darrick J. Wong
2020-08-27 7:00 ` Christoph Hellwig
2020-08-27 17:49 ` Darrick J. Wong
2020-08-28 6:08 ` Allison Collins
2020-08-26 22:06 ` [PATCH 10/11] xfs: trace timestamp limits Darrick J. Wong
2020-08-27 7:01 ` Christoph Hellwig
2020-08-28 6:08 ` Allison Collins
2020-08-26 22:06 ` [PATCH 11/11] xfs: enable big timestamps Darrick J. Wong
2020-08-28 6:09 ` Allison Collins
2020-08-27 6:41 ` [PATCH v4 00/11] xfs: widen timestamps to deal with y2038 Christoph Hellwig
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='CAOQ4uxiXNaboUgCs6A5zjfnMpmb8+=m+TaZ6fKj0-5sknie3Ag@mail.gmail.com' \
--to=amir73il@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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).