linux-kernel - Re: [RFC v2 03/83] Add super.h.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 15 Mar 2018 21:38:29 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Andiry Xu <jix024@....ucsd.edu>
Cc:     "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        Dan Williams <dan.j.williams@...el.com>,
        "Rudoff, Andy" <andy.rudoff@...el.com>, coughlan@...hat.com,
        Steven Swanson <swanson@...ucsd.edu>,
        Dave Chinner <david@...morbit.com>, Jan Kara <jack@...e.com>,
        swhiteho@...hat.com, miklos@...redi.hu,
        Jian Xu <andiry.xu@...il.com>, Andiry Xu <jix024@...ucsd.edu>
Subject: Re: [RFC v2 03/83] Add super.h.

On Thu, Mar 15, 2018 at 6:51 PM, Andiry Xu <jix024@....ucsd.edu> wrote:
> On Thu, Mar 15, 2018 at 2:05 AM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Thu, Mar 15, 2018 at 7:11 AM, Andiry Xu <jix024@....ucsd.edu> wrote:
>
> Superblock mtime is not a big problem as it is updated rarely. 64-bit
> seconds and 32-bit nanoseconds make the inode and log entry bigger,
> and updating file->atime cannot be done with a single 64bit update.
> That may be annoying and needs to use journaling.

If this is a big concern, you could use a format similar to what ext4 has:
30 bits of nanoseconds, and 34 bits of seconds, where the upper two
bits count the epoch. That gives you a time range from years 1902 to
2446.

You could also have a resolution of less than a nanosecond. Note
that today, the file time stamps generated by the kernel are in
jiffies resolution, so at best one millisecond. However, most modern
file systems go with the 64+32 bit timestamps because it's not all
that expensive.

      Arnd