From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752639AbeAZJEv (ORCPT ); Fri, 26 Jan 2018 04:04:51 -0500 Received: from mail-ot0-f196.google.com ([74.125.82.196]:38531 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752414AbeAZJEp (ORCPT ); Fri, 26 Jan 2018 04:04:45 -0500 X-Google-Smtp-Source: AH8x2241N2v8cHGSUzVerjTbt/ubZUNd5ZhYfG28OqCLWPkSAU2vuSVeBHhZmFzwy3tNUXsqk+c2VV58TZnO9+nGUNM= MIME-Version: 1.0 In-Reply-To: <0725a45f-45ee-7346-12ee-c3cc4b862654@landley.net> References: <1516850875-25066-1-git-send-email-takondra@cisco.com> <1516850875-25066-2-git-send-email-takondra@cisco.com> <0725a45f-45ee-7346-12ee-c3cc4b862654@landley.net> From: Arnd Bergmann Date: Fri, 26 Jan 2018 10:04:43 +0100 X-Google-Sender-Auth: _lMmWciD43NRGdg9b2q4eiW0jO8 Message-ID: Subject: Re: [PATCH v2 01/15] Documentation: add newcx initramfs format description To: Rob Landley Cc: Taras Kondratiuk , "H. Peter Anvin" , Al Viro , Mimi Zohar , Jonathan Corbet , James McMechan , initramfs@vger.kernel.org, Victor Kamensky , linux-doc@vger.kernel.org, Linux Kernel Mailing List , LSM List , xe-linux-external@cisco.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 26, 2018 at 3:39 AM, Rob Landley wrote: > The problem with 1 second timestamps was you honestly could confuse > "make" about which file was newer once an exec() could complete in the > same second having done real work. That was the motivating issue causing > the change, going to nanoseconds was just the big hammer of "this is > large enough it won't matter again in our lifetimes". But nanosecond > time stamps are recording more jitter than useful information, and that > seems unlikely to change this century? Sure, the only thing we really need the nanosecond timestamp for is to keep them identical. E.g. if you use cpio to make an exact copy of a file system, using microseconds timestamps will round all mtime values. If you then use 'rsync' to compare/update the two copies without passing a --modify-window= or --size-only, it will have to read all files in rather then skipping those with identical size and mtime. Side note: the default behavior for file systems is actually to only use the coarse timestamps of the last timer tick, so you actually do get identical timestamps in practice, plus six digits of nonsense: (on tmpfs) $ for i in {000..999} ; do > $i ; done; stat --format="%y" * | uniq -c 86 2018-01-26 10:01:48.811135084 +0100 469 2018-01-26 10:01:48.815135143 +0100 445 2018-01-26 10:01:48.819135201 +0100 Arnd