Date: Sun, 16 Feb 2003 12:25:10 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Juli Mallett <jmallett@FreeBSD.org> Cc: Kirk McKusick <mckusick@FreeBSD.org>, <src-committers@FreeBSD.org>, <cvs-src@FreeBSD.org>, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sbin/newfs mkfs.c src/sys/ufs/ffs ffs_alloc.c ffs_vfsops.c Message-ID: <20030216121332.Y20233-100000@gamplex.bde.org> In-Reply-To: <20030214153328.A78405@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 Feb 2003, Juli Mallett wrote: > * De: Kirk McKusick <mckusick@FreeBSD.org> [ Data: 2003-02-14 ] > [ Subjecte: cvs commit: src/sbin/newfs mkfs.c src/sys/ufs/ffs ffs_alloc.c ffs_vfsops.c ] > > mckusick 2003/02/14 13:31:58 PST > > > > Modified files: > > sbin/newfs mkfs.c > > sys/ufs/ffs ffs_alloc.c ffs_vfsops.c > > Log: > > Replace use of random() with arc4random() to provide less guessable > > values for the initial inode generation numbers in newfs and for > > newly allocated inode generation numbers in the kernel. > > Are the sequences for it also repeatable in the newfs case for e.g. the > regression tests, where it is used unseeded? Probably not. Randomness caused me problems in the kernel when I tried to figure out why soft-updates allocated blocks more 10-30% more pessimally than !soft-updates (for the benchmark of reading back files in creation order after untarring /usr/src to a new file system and remounting). I just ifdefed out the randomness, but should have done more for cylinder group allocation since the pessimization might depend on that. IIRC, soft-updates gives some randomness anyway because it delays some allocations. The pessimization seemed to have something to do with not putting blocks in such a good place for delayed allocations. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030216121332.Y20233-100000>