Date: Fri, 09 Jun 2006 11:20:09 -0600 From: Scott Long <scottl@samsco.org> To: Mikhail Teterin <mi+mx@aldan.algebra.com> Cc: fs@freebsd.org Subject: Re: heavy NFS writes lead to corrup summary in superblock Message-ID: <4489ADC9.3090809@samsco.org> In-Reply-To: <200606091313.04913.mi%2Bmx@aldan.algebra.com> References: <20060609065656.31225.qmail@web30313.mail.mud.yahoo.com> <200606091253.37446.mi%2Bmx@aldan.algebra.com> <4489A8CC.8030307@samsco.org> <200606091313.04913.mi%2Bmx@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mikhail Teterin wrote: > п'ятниця 09 червень 2006 12:58, Scott Long написав: > >>Can you actually measure a performance difference with using the -b >>65535 option on newfs? All of the I/O is buffered anyways and >>contiguous data is already going to be written in 64k blocks. > > > My reasons for using the largest block size was more of the space > efficiency -- the fs typically holds no more than 20 files in 10 directories, > but the smallest file is 1Gb in length. This is also why I chose ufs1 (-O1) > over ufs2 -- we don't need ACLs on this filesystem. > The space savings you get from UFS1 is that the inodes are half the size and the indorect blocks can hold more block pointers. I don't believe that ACLs play a difference here. > I never benchmarked the speed on the single drives, other than to compare with > my RAID5 array (which puzzlingly always loses to a single drive, but that's a > different story). All depends on access alignment and cache behaviour. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4489ADC9.3090809>