From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: [PATCH 86/87] fs: switch timespec64 fields in inode to discrete integers Date: Fri, 29 Sep 2023 07:32:09 +0100 Message-ID: <636661.1695969129@warthog.procyon.org.uk> References: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel@kernel.org> <20230928110554.34758-1-jlayton@kernel.org> <20230928110554.34758-2-jlayton@kernel.org> <6020d6e7-b187-4abb-bf38-dc09d8bd0f6d@app.fastmail.com> <20230928171943.GK11439@frogsfrogsfrogs> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695969159; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6sGP1uczCLU0843N+bG6IAXvwld3ke34VDTuCS/8Xis=; b=icM5id3ZsQZyBUsXhTHXZ2y1/foe9iVcHhC/N13AXe7JE6kiTY0piqDuOMUA6u3x41vTyB tm3z1aOmJYUTwDBlifBXPGi7xvSDqDIOSTrJ2V7ij+2F24kyOlqw18U7hqU3VaqBiSrmrw qA/K6vCzuFpNGzbpEi9FsJ8wwz9P9HQ= In-Reply-To: <6a6f37d16b55a3003af3f3dbb7778a367f68cd8d.camel-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> List-Id: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jeff Layton Cc: "Darrick J. Wong" , Arnd Bergmann , Alexander Viro , Christian Brauner , Linus Torvalds , David Sterba , Amir Goldstein , Theodore Ts'o , "Eric W. Biederman" , Kees Cook , Jeremy Kerr , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , Greg Kroah-Hartman , Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= Jeff Layton wrote: > Correct. We'd lose some fidelity in currently stored timestamps, but as > Linus and Ted pointed out, anything below ~100ns granularity is > effectively just noise, as that's the floor overhead for calling into > the kernel. It's hard to argue that any application needs that sort of > timestamp resolution, at least with contemporary hardware. Albeit with the danger of making Steve French very happy;-), would it make sense to switch internally to Microsoft-style 64-bit timestamps with their 100ns granularity? David