joshua,
you're probably not going to like my answer (since it is one of those 'do
lots of work now for less work later' options), but we use logical volume
managers on most of the production systems around here. you didn't say
what operating system you're using but AIX, HPUX, Solaris and now even
linux (with the Linux LVM project at sistina.com and now the EVMS port of
AIX's excellent LVM to linux as well at sourceforge.net/projects/evms).
all of these solutions allow a properly-prepared filesystem (in linux ext2
and reiser can both apply) to be resized as the underlying logical volume
is increased in size. once you go down this route, you'll never want to
go back to static, bios-based partitions.
anyway, this doesn't solve your problem in the short run, but it would
have solved your problem if you'd gone this direction several months ago
(ach, the irony!).
todd underwood
vice president &
chief technology officer
oso grande technologies, inc.
[EMAIL PROTECTED]
On Wed, 30 May 2001, Joshua Nichols wrote:
> Date: Wed, 30 May 2001 09:02:22 -0400
> From: Joshua Nichols <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: /var partition, queue size, and sendmail
>
> I recently discovered that my /var partition is not going to be large enough
> to accomodate my queue at certain times, and was hoping for some insight.
>
> As a temporary fix, I moved the queue to another partition (/home of all
> places) and created a symbolic link. I realize that there are some security
> concerns with this solution, so I am seeking advice. Is there a
> (reasonably) safe utility to resize my partitions without starting over
> (which is not really an option)? Is there another acceptable place to store
> the queue? And if so, is a symbolic link acceptable, or should I recompile
> to reflect the new queue location? Are there performance concerns here?
> Here's my partition table, and the output of 'df' for your consideration.
> The system is RedHat 7.0.
>
> partition table:
> Disk /dev/sda: 255 heads, 63 sectors, 2202 cylinders
> Units = cylinders of 16065 * 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 3 24066 83 Linux
> /dev/sda2 4 2202 17663467+ 5 Extended
> /dev/sda5 4 1002 8024436 83 Linux
> /dev/sda6 1003 2001 8024436 83 Linux
> /dev/sda7 2002 2034 265041 83 Linux
> /dev/sda8 2035 2067 265041 83 Linux
> /dev/sda9 2068 2100 265041 82 Linux swap
>
> df:
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/sda8 256667 243418 0 100% /
> /dev/sda1 23302 9106 12993 42% /boot
> /dev/sda6 7898380 97088 7400072 2% /home
> /dev/sda5 7898380 1000684 6496476 14% /usr
> /dev/sda7 256667 57363 186052 24% /var
>
> The cause of the large queue is a mailing list that sends about 150,000
> messages at 10-25k per message once a week (via qmail's replacement for
> sendmail), so I figure I'll bring up the large queue problem as well. I
> know this borders on an FAQ, but what I'm not sure of is this--is there
> /any/ way to avoid the queue size limit of 20ish thousand messages? As I
> understand it, the big-todo patch doesn't actually solve it, it just splits
> up the todo directory, and conf-split is only able to increase performance.
> Please tell me I'm wrong, because I'm not /positive/ that this will be an
> avoidable problem in the future.
>
> Thanks to everyone for any suggestions they can offer.
>
>
> --joshua.
>
>
>
