Date: Wed, 26 Sep 2001 18:03:01 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: Butch Evans <butch@sheltonbbs.com> Cc: Freebsd-ISP <freebsd-isp@FreeBSD.ORG> Subject: Re: couple of questions Message-ID: <Pine.BSF.4.21.0109261733380.12699-100000@ren.sasknow.com> In-Reply-To: <Pine.BSF.4.21.0109242343130.10358-100000@216-41-137-20.semo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Butch Evans wrote to Freebsd-ISP: > First of all, I want to add another disk to my server. I will use > this disk exclusively for log files. As you know, the logs can grow > quite large, so I wonder about the block size. Is it better to use a > larger than 8192 block size? Pros and cons would be helpful. I doubt it... You're not going to really waste any space with a larger blocksize, because presumably the number of log files you have will be small. But then again, you're not going to gain much either. Logs are written in small pieces (line by line, maybe buffered in small chunks), but since they're written to a lot, having a really huge blocksize means that every time they're written, you're moving around larger blocks and larger frags... So in that case, larger blocks might actually hinder performance. Depending on what sort of caching you have, you probably won't notice. 8192/1024 is good for most everything these days. Turn your bytes per inode way up. Otherwise, on large drives, you'll have WAY more inodes than you'll ever use, which wastes space. The default is to allocate one inode per every 4096 bytes! (So, unless you have a million or so fragment-size files, you probably want to increase that :-). Other than that, don't be too tempted to play with newfs/tunefs options... There isn't a lot to be gained, and many settings can cause problems (sometimes WEIRD ones ;-) many of them are legacy options that don't apply to newer, smarter controllers. > Next, I will be moving my existing logfiles to this disk. Is > something like the following a good plan (new disk will be mounted > as /var/logs): > > mv -R /var/log/* /var/logs > mv /var/log /var/log.old > ln -sf /var/logs /var/log > > Is there a better method? I don't mind losing a few lines of log > entries during the move, I am just concerned about unknown side > effects. Well, assuming your new drive is not hot-pluggable, you're going to have to shut the system down to install it anyway... So, when you bring the system up with the new drive, newfs, disklabel, and mount it in single user mode, and while you're still in single user, do something like what you mention above. If you do this while in single user mode, it will probably only take a minute or two (unless you have many GB of logs), but you won't lose any log data, and you won't have to worry about restarting syslog and other daemons that keep open files in /var/log). > On a side note...does anyone have a script to clean the entries in an > apache log of the junk requests from the Code Red and Nimda worm? Who needs a script? :-) grep -v system32/cmd.exe access.log >access.filtered.log Run the same command on error.log > This is something I will be using in my daily maint script until the > storm starts to pass. Just wrap that in a shell script. It is recommended that you run this on log files that have already been rotated. Otherwise, you will have locking problems and/or cause grief with apache writing further info to logs. Not quite sure exactly what your scenario is in that regard, so I'll refrain from speculation ;-) > I am more familiar with perl than awk or sed (or other scripting > languages), so please send in that language, if possible. > > TIA > > -- Ryan Thompson <ryan@sasknow.com> Network Administrator, Accounts SaskNow Technologies - http://www.sasknow.com #106-380 3120 8th St E - Saskatoon, SK - S7H 0W2 Tel: 306-664-3600 Fax: 306-664-1161 Saskatoon Toll-Free: 877-727-5669 (877-SASKNOW) North America To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109261733380.12699-100000>