From owner-freebsd-current@freebsd.org Sat Jun 17 02:48:59 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D2AAD90B00; Sat, 17 Jun 2017 02:48:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A87AC7A6D8; Sat, 17 Jun 2017 02:48:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v5H2mptV094830 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 17 Jun 2017 05:48:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v5H2mptV094830 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v5H2moBR094829; Sat, 17 Jun 2017 05:48:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 17 Jun 2017 05:48:50 +0300 From: Konstantin Belousov To: Mark Millard Cc: FreeBSD Current , freebsd-hackers@freebsd.org, FreeBSD PowerPC ML Subject: Re: INO64 in head: Does sys/boot/common/ufsread.c need its "typedef uint32_t ufs_ino_t;" replaced? Message-ID: <20170617024850.GB2088@kib.kiev.ua> References: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3AF2C2DB-1A61-4EC3-BCB7-B05D99273561@dsl-only.net> User-Agent: Mutt/1.8.2 (2017-04-18) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 02:48:59 -0000 On Fri, Jun 16, 2017 at 05:01:43PM -0700, Mark Millard wrote: > buildworld via clang for powerpc64 and powerpc fails for lack of > `__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size > code. But this lead to me looking around and I found a conceptually > separate possible issue. . . > > sys/sys/_types.h : > > typedef __uint64_t __ino_t; /* inode number */ > > # find /usr/src/sys/ -exec grep __ino_t {} \; -print | more > typedef __ino_t ino_t; > /usr/src/sys/sys/stat.h > typedef __ino_t ino_t; /* inode number */ > /usr/src/sys/sys/types.h > typedef __uint64_t __ino_t; /* inode number */ > /usr/src/sys/sys/_types.h > typedef __ino_t ino_t; > /usr/src/sys/sys/dirent.h > > > sys/boot/common/ufsread.c : > > . . . > #include > #include > #include > . . . > typedef uint32_t ufs_ino_t; > . . . > > Note the 32-bit type above. The headers included > have use of the 64-bit ino_t type as well, for > example: > > sys/ufs/ufs/diniode.h : > > . . . > #define UFS_ROOTINO ((ino_t)2) > . . . > #define UFS_WINO ((ino_t)1) > . . . > > sys/ufs/ffs/fs.h : > > . . . > #define ino_to_cg(fs, x) (((ino_t)(x)) / (fs)->fs_ipg) > #define ino_to_fsba(fs, x) \ > ((ufs2_daddr_t)(cgimin(fs, ino_to_cg(fs, (ino_t)(x))) + \ > (blkstofrags((fs), ((((ino_t)(x)) % (fs)->fs_ipg) / INOPB(fs)))))) > #define ino_to_fsbo(fs, x) (((ino_t)(x)) % INOPB(fs)) > . . . > > > I believe the powerpc64/powerpc issue > gives evidence of ino_t being used in > addition ot ufs_ino_t in > sys/boot/common/ufsread.c 's fsread_size . > > > Other things that look 32-bit inode-ish: > (I do not claim to know that any of this > matters.) > > sys/ufs/ufs/dir.h has: > > struct direct { > u_int32_t d_ino; /* inode number of entry */ > . . . > struct dirtemplate { > u_int32_t dot_ino; > . . . > u_int32_t dotdot_ino; > . . . > > struct odirtemplate { > u_int32_t dot_ino; > . . . > u_int32_t dotdot_ino; > . . . > > > sys/ufs/ffs/fs.h has: > > struct jrefrec { > . . . > uint32_t jr_ino; > > struct jmvrec { > . . . > uint32_t jm_ino; > > struct jblkrec { > . . . > uint32_t jb_ino; > > struct jtrncrec { > . . . > uint32_t jt_ino; UFS uses 32bit inodes, changing to 64bit is both pointless currently, and causes on-disk layout incompatibilities. As a consequence, use of ino_t (64bit) or uint32_t for inode numbers are almost always interchangeable, unless used for specifying on-disk layout. UFS correctly uses (and was changed to use) uint32_t for inode numbers in the disk-layout definitions. Other places, which calculate inode numbers from inode block numbers, or do some other calculations with inodes, are fine with either width. That is, I believe that all instances which I looked at during the ino64 preparation are fine.