From owner-freebsd-fs@freebsd.org Wed May 8 18:13:25 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30918158FBC2 for ; Wed, 8 May 2019 18:13:25 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4781888124; Wed, 8 May 2019 18:13:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id E753D3DB368; Thu, 9 May 2019 04:13:13 +1000 (AEST) Date: Thu, 9 May 2019 04:13:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Conrad Meyer cc: Rick Macklem , "freebsd-fs@freebsd.org" Subject: Re: test hash functions for fsid In-Reply-To: Message-ID: <20190509033852.W1574@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=P6RKvmIu c=1 sm=1 tr=0 cx=a_idp_d a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=dwDVpSKmk84E3L1OXAwA:9 a=uzXCp8bNZQQqBMJV:21 a=0mOM27thKD44Px-G:21 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: 4781888124 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.42 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-5.29 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[42.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; MX_INVALID(0.50)[cached]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.75)[-0.753,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.74)[ip: (-7.68), ipnet: 211.28.0.0/14(-3.34), asn: 4804(-2.66), country: AU(-0.01)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 18:13:25 -0000 On Wed, 8 May 2019, Conrad Meyer wrote: Another reply. > (A) FSIDs themselves have poor initial distribution and *very* few > unique bits (i.e., for filesystems that use vfs_getnewfsid, the int32 > fsid val[1] will be identical across all filesystems of the same type, > such as NFS mounts). The remaining val[0] is unique due to an > incrementing global counter. You could pretty easily extract the > vfs_getnewfsid() code out to userspace to simulate creating a bunch of > fsid_t's and run some tests on that list. It is a bug to actually use val[1] or 64-bit dev_t. Using it is either unnecessary because val[0] is unique, or breaks compat syscalls. See my previous reply. (I have a patch to make the compat syscalls fail if they would truncate the dev_t, but it is too strict to be the default and I forget if I committed it). > It isn't a real world > distribution but it would probably be pretty close, outside of ZFS. > ZFS FSIDs have 8 bits of shared vfs type, but the remaining 56 bits > appears to be generated by arc4rand(9), so ZFS FSIDs will have good > distribution even without hashing. Bug in zfs. Even stat(1) doesn't understand these 64-bit numbers. It misformats them in decimal: $ stat ~ 16921688315829575803 2179998 drwxr-xr-x 62 bde bde 18446744073709551615 85 "Nov 25 21:21:07 2016" "May 8 16:33:55 2019" "May 8 16:33:55 2019" "Sep 28 00:06:41 2015" 5632 24 0x800 /home/bde The first large number is st_dev and the second large number is st_rdev. The decimal formatting of these is hard enough to read when they are 32 bits. The 1844 number looks a like it is near UINT64_MAX, and is in fact exactly that, so it is far from unique. It is apparently just NODEV = (dev_t)(-1). This is correct except for the formatting, while in ffs st_rdev is garbage except for actual devices, since ufs_getattr() sets va_rdev to di_rdev even for non-devices, but for non-devices di_rdev is an alias for the first block number. I did commit my checks for truncation of dev_t's (r335035 and r335053). Fixing makedev() put the synthetic major number 255 in vfs_getnewfsid() back in the low 32 bits, so the checks usually pass for nfs. However, for zfs, they would often fail for the large number in st_dev, and always fail for regular files for the large number NODEV = UINT64_MAX in st_rdev. They should fail for NODEV for regular files on all file systems. Bruce