Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals

From	Deepa Dinamani <deepa.kernel@gmail.com>
Newsgroups	linux.kernel
Subject	Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals
Date	2016-02-13 08:00 +0100
Message-ID	<r1Cls-1eu-3@gated-at.bofh.it> (permalink)
References	<r1id4-51c-15@gated-at.bofh.it> <r1mA2-847-7@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

> Regarding the three versions, I think all of them are doable
> doable, and they all have their upsides and downsides but no
> showstoppers.

I agree that all the approaches are doable.

> Let me summarize what I see in the patches:
>
> 2a is the smallest set of changes in number of lines, as you indicated
>    in the previous discussion (I was skeptical here initially, but
>    you were right). The main downside is that each patch has to
>    carefully consider what happens at the point when the type gets
>    flipped, so that printk format strings are correct and assignments
>    to local variables don't truncate the range. It also requires
>    changing the types again after the VFS change, but that is
>    something we can automate using coccinelle.

2c has the same downside as this.
It also has to carefully consider what happens when you switch end filesystems
to timespec64, be it for printks or assignments.
I would say that the effort to do this was the same for 2a and 2c.

And, 2c also needs to get rid of the abstraction macros when vfs is transitioned
to using timespec64.

> 2b has the main advantage of not changing behavior with the flip, so
>    we can convert all file systems to use vfs_time relatively easily
>    and then later make them actually use 64-bit timestamps with
>    a patch that each file system developer can do for themselves.
>    One downside is that it leads to rather ugly code as discussed
>    before, examples are in "[RFC v2b 5/5] fs: xfs: change inode
>    times to use vfs_time data type" and "[RFC v2b 3/5] fs: btrfs:
>    Use vfs_time accessors".

Here is the breakup of the number of changes required from the table
in the cover letter(https://lkml.org/lkml/2016/2/12/76):

* # Changes needed in 2a = row 1 + row 7 + row 8 + row 9 + row 10
                        = 34 + 80 + 10 + 3 + 3 = 130
* # Changes needed in 2b = row 1 + row 4 + row 5 + row 6 + row 7 * (~3)
                        = 34 + 80 + 141 + 74 + 85 + 240 = 654
* # Changes needed in 2c = Changes in 2b + some more

It is clear to see from the above table that number of such changes will be
considerably more for approaches 2b and 2c.

And, 2b is not even close to what we want to achieve and will again confuse
developers even more as there will be 2 sets of abstraction apis now:
1. vfs_time apis
2. timespec64 to timespec/ timespec to timespec64 apis
Since there is no clean up effort here after vfs is switched over, we are just
making all filesystems that use these apis harder to read.

> 2c gets us the furthest along the way for the conversion, close
>    to where we want to end up in the long run, so we could do that
>    to file systems one by one. The behavior change is immediate,
>    so there are fewer possible surprises than with 2a, but it
>    also means the most upfront work.

2c abstractions can be used in more than one way.
And, 2c also introduces a new timestamp data type along with
timespec64 in the filesystem code.
The above two factors can make it confusing for the developers
until we transition vfs and remove abstractions from individual
filesystems. And, this is a problem as we want to remove
abstractions in a different kernel release than the one we do the
transition in, as we discussed previously.

2a still seems like the right choice to me.
And, will have the least number of changes.

As Arnd thinks all of them are doable, if anybody else has other
concerns we missed
please comment.

-Deepa

Thread

[RFC v2] vfs 64 bit time transition proposals Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:30 +0100
  [RFC v2a 12/12] fs: xfs: change inode times to use vfs_time data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 10/12] fs: ceph: Replace timespec data type with vfs_time Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 06/12] fs: btrfs: Change btrfs_inode.i_otime to use vfs_time data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 02/12] fs: cifs: Change cifs_fscache_inode_auxdata to use vfs_time data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 09/12] fs: ceph: Change encode and decode functions to use vfs_time Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 04/12] fs: cifs: Make cnvrtDosUnixTm() y2038 safe Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 05/12] fs: cifs: Use vfs_time_get_real_* time functions Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
  [RFC v2a 00/12] vfs 64 bit time transition proposal Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
    [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
      Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of  timespec Dave Chinner <david@fromorbit.com> - 2016-02-13 23:10 +0100
        Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-14 02:50 +0100
          Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-14 03:10 +0100
          Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of  timespec Dave Chinner <david@fromorbit.com> - 2016-02-14 22:10 +0100
            Re: [RFC v2a 11/12] net: ceph: use vfs_time data type instead of timespec Arnd Bergmann <arnd@arndb.de> - 2016-02-17 10:40 +0100
    [RFC v2a 07/12] fs: btrfs: Use vfs_time data type for btrfs_update_time() Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
    [RFC v2a 08/12] fs: btrfs: Change timespec data types to use vfs_time Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:40 +0100
    [RFC v2a 03/12] fs: cifs: Change cifs_fattr timestamps data type to vfs_time Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
    [RFC v2a 01/12] vfs: Add vfs_time abstractions Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
  [RFC v2b 4/5] fs: ceph: Use vfs timestamp accessors Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
  [RFC v2b 2/5] fs: cifs: Use vfs_time accessors Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
  [RFC v2b 3/5] fs: btrfs: Use vfs_time accessors Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
    Re: [RFC v2b 3/5] fs: btrfs: Use vfs_time accessors Arnd Bergmann <arnd@arndb.de> - 2016-02-12 15:00 +0100
      Re: [RFC v2b 3/5] fs: btrfs: Use vfs_time accessors Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-13 08:10 +0100
  [RFC v2b 0/5] vfs 64 bit time transition proposal Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
    [RFC v2b 1/5] vfs: Add vfs_time accessors Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 10:50 +0100
    [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
      Re: [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data  type Dave Chinner <david@fromorbit.com> - 2016-02-13 03:20 +0100
        Re: [Y2038] [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type Arnd Bergmann <arnd@arndb.de> - 2016-02-13 16:00 +0100
          Re: [Y2038] [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time  data type "David F." <df7729@gmail.com> - 2016-02-13 17:00 +0100
  [RFC v2c 8/8] fs: xfs: change inode times to use vfs_time data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 2/8] fs: cifs: Change auxdata to struct timespec64 data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 1/8] vfs: Add vfs_time abstractions Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 4/8] fs: cifs: Make cnvrtDosUnixTm() y2038 safe Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 6/8] fs: btrfs: Use vfs timestamp abstraction helper Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 5/8] fs: btrfs: Change btrfs_inode.i_otime to vfs_time data type Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 3/8] fs: cifs: Change cifs_fattr timestamps data type to timespec64 Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  [RFC v2c 0/8] vfs 64 bit time transition proposal Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
    [RFC v2c 7/8] fs: ceph: Use vfs timestamp abstraction helpers Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-12 11:00 +0100
  Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals Arnd Bergmann <arnd@arndb.de> - 2016-02-12 15:10 +0100
    Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-13 08:00 +0100
      [RFC v2] vfs 64 bit time transition proposals Deepa Dinamani <deepa.kernel@gmail.com> - 2016-02-13 13:00 +0100

csiph-web