Date: Thu, 17 Jan 2002 13:20:02 -0800 (PST) From: Ryan Dooley <dooleyr@missouri.edu> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/33941: /usr/sbin/dev_mkdb dumps core Message-ID: <200201172120.g0HLK2087072@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/33941; it has been noted by GNATS. From: Ryan Dooley <dooleyr@missouri.edu> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: <bug-followup@freebsd.org>, <dillon@FreeBSD.org> Subject: Re: bin/33941: /usr/sbin/dev_mkdb dumps core Date: Thu, 17 Jan 2002 15:13:34 -0600 (CST) Hey, > I'd be _very_ careful trying a block size anything larger than 16384. > I've heard horrible things about larger block sizes. I'm pretty sure > Matt Dillon warned that >16384 block sizes would cause undesirable > behaviour in the VM sysystem. > > Certainly, VM problems could account for your SEGV. > > Matt? Am I smoking crack, or did you say Very Bad Things about the VM > system and block sizes >16384? Uh oh, I have a server then with 65536/8192 (bs,fr) for a 953GB fiber channel raid. I've not noticed anything bad off hand (it was CVSup'd on Saturday around midnight CST. This actually concearns me more than my workstation :-) We changed the block/frag size to speed up file system checks when we had to fsck that partition (which holds 41000+ user home directories). We went from fsck's taking about 120 minutes to 15 minutes which we drastically needed. I have had reports that reads over NFS (a client running a program on a file (SAS data)) took two or three attempts to initialy access the file before sas ran with it. Sounded like a NFS cache issue, but I couldn't reproduce the error myself. (AIX client to FreeBSD server). As the semester is about to start, I can't reformat that array right now. Ryan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201172120.g0HLK2087072>