From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [RFC 00/32] making inode time stamps y2038 ready Date: Wed, 04 Jun 2014 17:10:24 -0700 Message-ID: <538FB570.8000502@zytor.com> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <201406041703.47592.arnd@arndb.de> <8770583.6XeZxCxOY8@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <8770583.6XeZxCxOY8@wuerfel> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fuse-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Arnd Bergmann , Nicolas Pitre Cc: hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, Dave Chinner , linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Joseph S. Myers" , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-afs-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, cluster-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, coda-ETDLCGt7PQU3uPMLIKxrzw@public.gmane.org, geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, codalist-ySnCqBnJi5yMVn35/9/JlcWGCVk0P7UB@public.gmane.org, fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, reiserfs-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org, john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ntfs-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, logfs-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org, linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lftan-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org, ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org List-Id: ceph-devel.vger.kernel.org On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal time_t/timespec to 64-bit > seconds for everything. > How much of a performance issue is it to make time_t 64 bits, and for the bits there are, how hard are they to fix? -hpa ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech From mboxrd@z Thu Jan 1 00:00:00 1970 From: H. Peter Anvin Date: Wed, 04 Jun 2014 17:10:24 -0700 Subject: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready In-Reply-To: <8770583.6XeZxCxOY8@wuerfel> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <201406041703.47592.arnd@arndb.de> <8770583.6XeZxCxOY8@wuerfel> Message-ID: <538FB570.8000502@zytor.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal time_t/timespec to 64-bit > seconds for everything. > How much of a performance issue is it to make time_t 64 bits, and for the bits there are, how hard are they to fix? -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:39895 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753308AbaFEAOO (ORCPT ); Wed, 4 Jun 2014 20:14:14 -0400 Message-ID: <538FB570.8000502@zytor.com> Date: Wed, 04 Jun 2014 17:10:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [RFC 00/32] making inode time stamps y2038 ready References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <201406041703.47592.arnd@arndb.de> <8770583.6XeZxCxOY8@wuerfel> In-Reply-To: <8770583.6XeZxCxOY8@wuerfel> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann , Nicolas Pitre Cc: Dave Chinner , hch@infradead.org, linux-mtd@lists.infradead.org, logfs@logfs.org, linux-afs@lists.infradead.org, "Joseph S. Myers" , linux-arch@vger.kernel.org, linux-cifs@vger.kernel.org, linux-scsi@vger.kernel.org, ceph-devel@vger.kernel.org, cluster-devel@redhat.com, coda@cs.cmu.edu, geert@linux-m68k.org, linux-ext4@vger.kernel.org, codalist@telemann.coda.cs.cmu.edu, fuse-devel@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, john.stultz@linaro.org, tglx@linutronix.de, linux-nfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, linux-fsdevel@vger.kernel.org, lftan@altera.com, linux-btrfs@vger.kernel.org Message-ID: <20140605001024.t7kwb7PXUJc_yBQNPD_NVuLzkM3qQqKHkTx7jVBzRnI@z> On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal time_t/timespec to 64-bit > seconds for everything. > How much of a performance issue is it to make time_t 64 bits, and for the bits there are, how hard are they to fix? -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <538FB570.8000502@zytor.com> Date: Wed, 04 Jun 2014 17:10:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 To: Arnd Bergmann , Nicolas Pitre Subject: Re: [RFC 00/32] making inode time stamps y2038 ready References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <201406041703.47592.arnd@arndb.de> <8770583.6XeZxCxOY8@wuerfel> In-Reply-To: <8770583.6XeZxCxOY8@wuerfel> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hch@infradead.org, Dave Chinner , linux-mtd@lists.infradead.org, linux-f2fs-devel@lists.sourceforge.net, ceph-devel@vger.kernel.org, "Joseph S. Myers" , linux-arch@vger.kernel.org, linux-cifs@vger.kernel.org, linux-scsi@vger.kernel.org, linux-afs@lists.infradead.org, cluster-devel@redhat.com, coda@cs.cmu.edu, geert@linux-m68k.org, linux-ext4@vger.kernel.org, codalist@telemann.coda.cs.cmu.edu, fuse-devel@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, john.stultz@linaro.org, tglx@linutronix.de, linux-nfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, logfs@logfs.org, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, lftan@altera.com, ocfs2-devel@oss.oracle.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal time_t/timespec to 64-bit > seconds for everything. > How much of a performance issue is it to make time_t 64 bits, and for the bits there are, how hard are they to fix? -hpa From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2211E7F3F for ; Wed, 4 Jun 2014 19:14:12 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id EE4AF8F8035 for ; Wed, 4 Jun 2014 17:14:11 -0700 (PDT) Received: from mail.zytor.com ([198.137.202.10]) by cuda.sgi.com with ESMTP id aa5BAQ2EoqBEqKks (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 04 Jun 2014 17:14:10 -0700 (PDT) Message-ID: <538FB570.8000502@zytor.com> Date: Wed, 04 Jun 2014 17:10:24 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [RFC 00/32] making inode time stamps y2038 ready References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <201406041703.47592.arnd@arndb.de> <8770583.6XeZxCxOY8@wuerfel> In-Reply-To: <8770583.6XeZxCxOY8@wuerfel> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Arnd Bergmann , Nicolas Pitre Cc: hch@infradead.org, linux-mtd@lists.infradead.org, linux-f2fs-devel@lists.sourceforge.net, ceph-devel@vger.kernel.org, "Joseph S. Myers" , linux-arch@vger.kernel.org, linux-cifs@vger.kernel.org, linux-scsi@vger.kernel.org, linux-afs@lists.infradead.org, cluster-devel@redhat.com, coda@cs.cmu.edu, geert@linux-m68k.org, linux-ext4@vger.kernel.org, codalist@telemann.coda.cs.cmu.edu, fuse-devel@lists.sourceforge.net, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, john.stultz@linaro.org, tglx@linutronix.de, linux-nfs@vger.kernel.org, linux-ntfs-dev@lists.sourceforge.net, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, logfs@logfs.org, linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, lftan@altera.com, ocfs2-devel@oss.oracle.com On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal time_t/timespec to 64-bit > seconds for everything. > How much of a performance issue is it to make time_t 64 bits, and for the bits there are, how hard are they to fix? -hpa _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: H. Peter Anvin Date: Wed, 04 Jun 2014 17:10:24 -0700 Subject: [Ocfs2-devel] [RFC 00/32] making inode time stamps y2038 ready In-Reply-To: <8770583.6XeZxCxOY8@wuerfel> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <201406041703.47592.arnd@arndb.de> <8770583.6XeZxCxOY8@wuerfel> Message-ID: <538FB570.8000502@zytor.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Arnd Bergmann , Nicolas Pitre Cc: hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org, Dave Chinner , linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-f2fs-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, ceph-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "Joseph S. Myers" , linux-arch-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-afs-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, cluster-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, coda-ETDLCGt7PQU3uPMLIKxrzw@public.gmane.org, geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, codalist-ySnCqBnJi5yMVn35/9/JlcWGCVk0P7UB@public.gmane.org, fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, reiserfs-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xfs-VZNHf3L845pBDgjK7y7TUQ@public.gmane.org, john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ntfs-dev-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, logfs-PCqxUs/MD9bYtjvyW6yDsg@public.gmane.org, linux-btrfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lftan-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org, ocfs2-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org On 06/04/2014 12:24 PM, Arnd Bergmann wrote: > > For other timekeeping stuff in the kernel, I agree that using some > 64-bit representation (nanoseconds, 32/32 unsigned seconds/nanoseconds, > ...) has advantages, that's exactly the point I was making earlier > against simply extending the internal time_t/timespec to 64-bit > seconds for everything. > How much of a performance issue is it to make time_t 64 bits, and for the bits there are, how hard are they to fix? -hpa