From: "Pali Rohár" <pali.rohar@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Arnd Bergmann <arnd@arndb.de>, Namjae Jeon <linkinjeon@gmail.com>,
Namjae Jeon <namjae.jeon@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
gregkh <gregkh@linuxfoundation.org>,
Valdis Kletnieks <valdis.kletnieks@vt.edu>,
sj1557.seo@samsung.com
Subject: Re: [PATCH v10 09/14] exfat: add misc operations
Date: Thu, 16 Jan 2020 17:00:51 +0100 [thread overview]
Message-ID: <20200116160051.adn7j7y5oshoe7qt@pali> (raw)
In-Reply-To: <20200116102307.GA16662@lst.de>
On Thursday 16 January 2020 11:23:07 Christoph Hellwig wrote:
> On Thu, Jan 16, 2020 at 11:19:47AM +0100, Pali Rohár wrote:
> > However, implementations should only record the value 00h for this
> > field when:
> >
> > 1. Local date and time are actually the same as UTC, in which case
> > the value of the OffsetValid field shall be 1
> >
> > 2. Local date and time are not known, in which case the value of the
> > OffsetValid field shall be 1 and implementations shall consider
> > UTC to be local date and time
>
> Given time zones in Linux are per session I think our situation is
> somewhat similar to 2.
Seems that 2. is really similar. Ok, storing by default in UTC make
sense, but still I'm thinking if there should be (or not) a mount option
which override default UTC timezone.
> > > Here I would just convert to UTC, which is what we store in the
> > > in-memory struct inode anyway.
> >
> > Ok. If inode timestamp is always in UTC, we should do same thing also
> > for exFAT.
>
> > Hm... both UTC and sys_tz have positives and negatives. And I'm not
> > sure which option is better.
>
> The one big argument for always UTC is simplicity. Always using UTC
> kills some arcane an unusual (for Linux file systems) code, and given
> how exfat implementations deal with the time zone on reading should
> always interoperate fine with other implementations.
Now I think that using UTC by default is the better option as sys_tz.
Simplicity and "no surprise" (container may use UTC, but kernel has
sys_tz in not in UTC) seems like a good arguments.
--
Pali Rohár
pali.rohar@gmail.com
next prev parent reply other threads:[~2020-01-16 16:00 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200115082818epcas1p4892a99345626188afd111ee263132458@epcas1p4.samsung.com>
2020-01-15 8:24 ` [PATCH v10 00/14] add the latest exfat driver Namjae Jeon
[not found] ` <CGME20200115082819epcas1p3303009557f8bf670b47991530f380ef7@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 01/14] exfat: add in-memory and on-disk structures and headers Namjae Jeon
[not found] ` <CGME20200115082819epcas1p3825d5bed592a8378ad26254d07d59b18@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 02/14] exfat: add super block operations Namjae Jeon
[not found] ` <CGME20200115082820epcas1p34ebebebaf610fd61c4e9882fca8ddbd5@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 03/14] exfat: add inode operations Namjae Jeon
2020-01-15 10:25 ` Arnd Bergmann
2020-01-15 13:39 ` Namjae Jeon
2020-01-17 9:25 ` Pali Rohár
2020-01-17 11:17 ` Pali Rohár
[not found] ` <CGME20200115082821epcas1p3db1f70cf53185c40934c3a754c65e648@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 04/14] exfat: add directory operations Namjae Jeon
2020-01-17 11:13 ` Pali Rohár
[not found] ` <CGME20200115082821epcas1p4d76d8668dfac70ae3e3889d4ccb6c3ee@epcas1p4.samsung.com>
2020-01-15 8:24 ` [PATCH v10 05/14] exfat: add file operations Namjae Jeon
2020-01-15 9:56 ` Arnd Bergmann
2020-01-15 13:07 ` Namjae Jeon
2020-01-17 9:18 ` Pali Rohár
2020-01-17 12:12 ` Namjae Jeon
[not found] ` <CGME20200115082822epcas1p37aca37dad0aa9159d7eddde01edfeec2@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 06/14] exfat: add fat entry operations Namjae Jeon
[not found] ` <CGME20200115082822epcas1p384d080724d8bb0a8cd4c3e3015a0895c@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 07/14] exfat: add bitmap operations Namjae Jeon
[not found] ` <CGME20200115082823epcas1p27ec5ff6d384f148d826529f573173b04@epcas1p2.samsung.com>
2020-01-15 8:24 ` [PATCH v10 08/14] exfat: add exfat cache Namjae Jeon
[not found] ` <CGME20200115082824epcas1p4eb45d088c2f88149acb94563c4a9b276@epcas1p4.samsung.com>
2020-01-15 8:24 ` [PATCH v10 09/14] exfat: add misc operations Namjae Jeon
2020-01-15 10:10 ` Arnd Bergmann
2020-01-15 13:30 ` Namjae Jeon
2020-01-15 13:38 ` Pali Rohár
2020-01-15 13:50 ` Arnd Bergmann
2020-01-15 14:24 ` Pali Rohár
2020-01-15 15:03 ` Arnd Bergmann
2020-01-15 15:39 ` Pali Rohár
2020-01-15 15:52 ` Arnd Bergmann
2020-01-16 10:19 ` Pali Rohár
2020-01-16 10:23 ` Christoph Hellwig
2020-01-16 16:00 ` Pali Rohár [this message]
2020-01-17 2:59 ` Namjae Jeon
2020-01-17 10:13 ` Arnd Bergmann
2020-01-17 12:13 ` Namjae Jeon
[not found] ` <CGME20200115082824epcas1p23a0fa255a5833c6dcd2479b384f37740@epcas1p2.samsung.com>
2020-01-15 8:24 ` [PATCH v10 10/14] exfat: add nls operations Namjae Jeon
[not found] ` <CGME20200115082825epcas1p1f22ddca6dbf5d70e65d3b0e3c25c3a59@epcas1p1.samsung.com>
2020-01-15 8:24 ` [PATCH v10 11/14] exfat: add Kconfig and Makefile Namjae Jeon
2020-01-15 9:39 ` Pali Rohár
2020-01-17 4:22 ` Namjae Jeon
2020-01-17 9:12 ` Pali Rohár
2020-01-17 11:59 ` Namjae Jeon
[not found] ` <CGME20200115082825epcas1p4a0d63d53d8737a84fe8867bc1e63811e@epcas1p4.samsung.com>
2020-01-15 8:24 ` [PATCH v10 12/14] exfat: add exfat in fs/Kconfig and fs/Makefile Namjae Jeon
[not found] ` <CGME20200115082826epcas1p117191a39ecccaef5a9b5cbe77b05c5a5@epcas1p1.samsung.com>
2020-01-15 8:24 ` [PATCH v10 13/14] MAINTAINERS: add exfat filesystem Namjae Jeon
[not found] ` <CGME20200115082826epcas1p3475ce2b4d03234dc96ced428be582eb3@epcas1p3.samsung.com>
2020-01-15 8:24 ` [PATCH v10 14/14] staging: exfat: make staging/exfat and fs/exfat mutually exclusive Namjae Jeon
2020-01-15 8:56 ` Greg KH
2020-01-15 13:06 ` Namjae Jeon
2020-01-15 9:47 ` [PATCH v10 00/14] add the latest exfat driver Pali Rohár
2020-01-15 13:05 ` Namjae Jeon
2020-01-16 10:51 ` Christoph Hellwig
2020-01-16 11:32 ` Pali Rohár
2020-01-16 13:01 ` Greg KH
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=20200116160051.adn7j7y5oshoe7qt@pali \
--to=pali.rohar@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=linkinjeon@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=namjae.jeon@samsung.com \
--cc=sj1557.seo@samsung.com \
--cc=valdis.kletnieks@vt.edu \
/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).