Date: Fri, 16 Jan 2009 13:12:27 -0600 From: "Rick C. Petty" <rick-freebsd2008@kiwi-computer.com> To: Brian McCann <bjmccann@gmail.com> Cc: freebsd-geom@freebsd.org Subject: Re: gvinum & gjournal Message-ID: <20090116191227.GA67515@keira.kiwi-computer.com> In-Reply-To: <2b5f066d0901160645n81c0296j1e714056da74c88e@mail.gmail.com> References: <2b5f066d0901141323j7c9a194eo4606d9769279037e@mail.gmail.com> <20090115025645.21ad2185.ota@j.email.ne.jp> <2b5f066d0901150410s7dc4e97v741d5edd2a4983a9@mail.gmail.com> <20090115172036.GA54383@keira.kiwi-computer.com> <2b5f066d0901160645n81c0296j1e714056da74c88e@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 16, 2009 at 09:45:44AM -0500, Brian McCann wrote: > > The only time I ever run fsck's is when the system is shutdown dirty > (and just about on every reboot, on the large arrays anyway, it almost > never background fsck's the array...it insists on doing it before the > rest of the system boots/loads). That's strange, I've not seen that before. Are you using softupdates and UFS2? FreeBSD 6.0 or later? I have had numerous crashes for various reasons and the filesystems are almost always dirty when I restart (or why would I restart?) but I have never seen it try to foreground fsck anything except root. If this is happening in your case, it would be nice to diagnose and fix that problem instead of working around it. > I've already got a few servers here > with UFS2 that occasionally crash or hang for various reasons and > reboot...and with large file systems (like 2 roughly 200GB arrays), > the system takes almost 1 hour to come back to life. I was really > hoping UFS2 would have solved this old problem...but it still pops > it's head back up now and then. :( I've had numerous crashes with several filesystems on the order of 200-500 GB each and although the background fsck can take some time, I've never had it forcibly happen in the foreground. Can you paste your /etc/rc.conf ? Also the time it takes to fsck is proportional to the filesystem size, number of inodes, and number of files/directories to check. When I make larger filesystems, I tend to reduce the number of inodes which greatly reduces fsck times. With lots of little files, it's usually a good idea to split filesystems into smaller, manageable pieces. Think about dump/restore times. Sure you can make a 16TB filesystem that can support trillions of files, but you can't expect it to perform well even in normal usage. UFS2 has some other limitations which prevents this from working to your advantage. Your best bet is to plan your filesystems better so you can manage dumps and fscks without terrible hassle or use ZFS and buy 32 gigs of RAM. -- Rick C. Petty
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090116191227.GA67515>