Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: 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>,
	Christoph Hellwig <hch@lst.de>,
	sj1557.seo@samsung.com
Subject: Re: [PATCH v10 09/14] exfat: add misc operations
Date: Thu, 16 Jan 2020 11:19:47 +0100
Message-ID: <20200116101947.4szdyfwpyasv5vpe@pali> (raw)
In-Reply-To: <CAK8P3a1iYPA9MrXORiWmy1vQGoazwHs7OfPdoHLZLJDWqu9jqA@mail.gmail.com>

On Wednesday 15 January 2020 16:52:12 Arnd Bergmann wrote:
> On Wed, Jan 15, 2020 at 4:39 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > On Wednesday 15 January 2020 16:03:12 Arnd Bergmann wrote:
> > > The vdso and kernel/time/ code are for maintaining the timezone through
> > > settimeofday()/gettimeofday(), and the drivers should probably all be changed
> > > to use UTC. The file systems (affs, fat, hfs, hpfs and udf) do this for
> > > compatibility with other operating systems that store the metadata in
> > > localtime.
> >
> > Ok. But situation for exFAT is quite different. exFAT timestamp
> > structure contains also timezone information. Other filesystems do not
> > store timezone into their metadata (IIRC udf is exception and also
> > stores timezone). So question is in which timezone we should store to
> > exFAT timestamps. This is not for compatibility with legacy systems, but
> > because of fact that filesystem supports feature which is not common for
> > other filesystems.
> >
> > Also, to make it more complicated exFAT supports storing timestamps also
> > in "unspecified" (local user) timezone, which matches other linux
> > filesystems.
> >
> > So for storing timestamp we have options:
> >
> > * Store them without timezone
> > * Store them in sys_tz timezone
> > * Store them in timezone specified in mount option
> > * Store them in UTC timezone
> >
> > And when reading timestamp from exFAT we need to handle both:
> >
> > * Timestamps without timezone
> > * Timestamps with timezone
> 
> Right.
> 
> > So what is the best way to handle timezone/timestamps?
> >
> > For me it looks sane:
> >
> > When storing use: mount option timezone. When not available then use
> > sys_tz. And when sys_tz is not set (it is possible?), do not specify
> > timezone at all. Maybe there should be a mount option which says that
> > timestamps on exfat are stored without timezone.
> 
> I would argue we should always store files in UTC, which seems to be
> the most consistent with other file systems, and can be understood
> by any other implementation that understands the timezone information
> on disk  or that expects UTC.

exFAT timezone information needs to be understand by any exFAT
implementation.

I looked into exFAT specification and it has following information how
implementation should choose timezone:

https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification#74101-offsetfromutc-field

  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

    3. UTC is not known, in which case the value of the OffsetValid
       field shall be 0

I'm not sure if storing time always in UTC is fine with specification.

Mount option which specify timezone can solve this problem, but only in
case when it is specified.

> > When reading timestamp with timezone: Convert timestamp to timezone
> > specified in mount option (or fallback to sys_tz or fallback to UTC).
> 
> 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.

> > And when reading timestamp without timezone: Pass it as is without
> > conversion, ignoring all timezone mount options and sys_tz.
> >
> > Arnd, what do you think about it?
> 
> The last case (reading timestamp without timezone) is the only
> one that I think we have to decide on: when reading an inode from
> disk into memory, we have to convert it into UTC in some form.
> 
> This is what I think the timezone mount option should be used
> for: if we don't know what the timezone was for the on-disk
> timestamp, use the one provided by the user.

I agree, this make sense.

> However, if none
> was specified, it should be either sys_tz or UTC (i.e. no
> conversion). I would prefer the use of UTC here given the
> problems with sys_tz, but sys_tz would be more consistent
> with how fs/fat works.

Hm... both UTC and sys_tz have positives and negatives. And I'm not
sure which option is better.

Do we know how Tuxera or Paragon solved this dilema in their exFAT
implementations? IIRC Paragon already sent their implementation to LKML.

-- 
Pali Rohár
pali.rohar@gmail.com

  reply index

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 [this message]
2020-01-16 10:23                         ` Christoph Hellwig
2020-01-16 16:00                           ` Pali Rohár
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 publically 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=20200116101947.4szdyfwpyasv5vpe@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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git