Re: Amanda 2.2.6, not using spool area
On Apr 10, 2001, [EMAIL PROTECTED] (Brian Cuttler) wrote:
Wondering if this isn't a "feature" of 2.2.6 and a must upgrade
for performance issue at our site.
The smaller problem partition is only 4 gig, the larger in excess
of 18, both partitions continue to grow.
I'm afraid you'll have to upgrade. In 2.4.1 or so, we have introduced
`chunksize', that lets Amanda back up large disks regardless of the
maximum holding disk file size.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Amanda 2.2.6, not using spool area
Paul,
Actually both amanda hosts are Solaris 5.6, one machine is its
own and only client, the other is its own client but also has
both solaris and irix clients.
In both cases its a local file system with the problem.
In both cases output is to a local DLT drive.
Establishing chunksize as a required parameter is a good reason
for me to upgrade. Can you tell me what it does ?
thanks,
Brian
Brian,
Just a quick thought: If your AMANDA tape host is running Linux, there is a
limit of 2.0Gb per file in an ext2 file system. (Even if you're not running
Linux, you might have a similar limit.) The chunksize also helps get around
file size limit problems.
Paul
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 10, 2001 10:52 AM
To: Alexandre Oliva
Cc: Brian Cuttler; [EMAIL PROTECTED]; J Chris Knight
Subject: Re: Amanda 2.2.6, not using spool area
Alex,
Holding disk on "wcnotes" is 36 gig (in a single partition) the
level 1 backup that went direct to tape last night was 11 gig
(5 gig from another partion, same system).
This is why I thought it wasn't a spool space issue. In this
case we should have had sufficient room as the 4 partitons
involved contributed 11 gig, 5 gig, 1 gig and .7 gig. Even with
all in spool at one time I would not expect to see this behaviour.
Not that I'm don't want to upgrade Amanda, but you know how it is.
Without the excuse its hard to pull the time from another project
to fix something that is working (and amanda is very reliable).
Besides, I don't like mystery behaviour.
This just doesn't look like a spool capacity issue ?
thanks,
Brian
On Apr 10, 2001, [EMAIL PROTECTED] (Brian Cuttler) wrote:
Wondering if this isn't a "feature" of 2.2.6 and a must upgrade
for performance issue at our site.
The smaller problem partition is only 4 gig, the larger in excess
of 18, both partitions continue to grow.
I'm afraid you'll have to upgrade. In 2.4.1 or so, we have introduced
`chunksize', that lets Amanda back up large disks regardless of the
maximum holding disk file size.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Amanda 2.2.6, not using spool area
Thank you. Paul Bort had the same thought.
I'd thought we'd exceeded the 2 gig barrier long ago - perhaps
that was only on some of the newer version amanda servers.
Thank you both - will schedule an upgrade to both amanda systems.
Oh - which release do you recommend. We don't need the latest
features, just solid function and stability - which amanda has
always provided. (but you know how people feel about the 'newest'
off the shelf - thanks to Microsoft).
thanks,
Brian
On Apr 10, 2001, [EMAIL PROTECTED] (Brian Cuttler) wrote:
Holding disk on "wcnotes" is 36 gig (in a single partition)
IIRC, before we introduced chunksize, Amanda would always dump
directly to tape any images expected to be larger than 2 Gb, because
of the 2Gb filesize limitation of some common filesystem types.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Amanda 2.2.6, not using spool area
I'm attempting to build Amanda 2.4.2p2 on Solaris 5.6 and finding the following... [newton] /local/source/etc/amanda/amanda-2.4.2p2 43 ./configure --with-user=bin --with-group=sys which seems to run to completion (we have notes from previous installation that talk about the --disable-libtool and other switches but they where only related to our IRIX compliation problems). output ending with... checking whether lockf locking works... (cached) no checking whether lnlock locking works... (cached) no configure: warning: *** No working file locking capability found! configure: warning: *** Be VERY VERY careful. creating ./config.status : : reating server-src/amstatus.pl creating tape-src/Makefile creating config/Makefile creating Makefile creating config/config.h config/config.h is unchanged The make however fails pretty quickly. [newton] /local/source/etc/amanda/amanda-2.4.2p2 44 make Making all in config Making all in common-src /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -c alloc.c gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -c alloc.c -o alloc.o In file included from /usr/include/sys/stream.h:26, from /usr/include/netinet/in.h:38, from /usr/include/netdb.h:96, from amanda.h:105, from alloc.c:33: /usr/include/sys/model.h:35: parse error before `/' In file included from /usr/include/netinet/in.h:38, from /usr/include/netdb.h:96, from amanda.h:105, from alloc.c:33: /usr/include/sys/stream.h:92: parse error before `}' /usr/include/sys/stream.h:92: warning: data definition has no type or storage class /usr/include/sys/stream.h:216: parse error before `queue_t' /usr/include/sys/stream.h:216: warning: no semicolon at end of struct or union /usr/include/sys/stream.h:218: warning: data definition has no type or storage class /usr/include/sys/stream.h:220: parse error before `}' /usr/include/sys/stream.h:274: parse error before `queue_t' /usr/include/sys/stream.h:274: warning: no semicolon at end of struct or union /usr/include/sys/stream.h:275: warning: data definition has no type or storage class /usr/include/sys/stream.h:425: parse error before `mblk_t' /usr/include/sys/stream.h:425: warning: no semicolon at end of struct or union /usr/include/sys/stream.h:427: parse error before `}' /usr/include/sys/stream.h:463: parse error before `mblk_t' /usr/include/sys/stream.h:463: warning: no semicolon at end of struct or union /usr/include/sys/stream.h:466: parse error before `}' /usr/include/sys/stream.h:479: field `copyreq' has incomplete type /usr/include/sys/stream.h:480: field `copyresp' has incomplete type *** Error code 1 make: Fatal error: Command failed for target `alloc.lo' Current working directory /local/source/etc/amanda/amanda-2.4.2p2/common-src *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Please note that I am doing the build from "my" account which is the member of a few nice unix "groups" but is not the root account nor especially privileged. thanks, Brian
Re: Amanda 2.2.6, not using spool area
I'm attempting to build Amanda 2.4.2p2 on Solaris 5.6 and finding the following... output ending with... checking whether lockf locking works... (cached) no checking whether lnlock locking works... (cached) no configure: warning: *** No working file locking capability found! configure: warning: *** Be VERY VERY careful. That's bad, and certainly does not happen on my Solaris systems. The "(cached)" marker indicates this is not the first time you ran ./configure, which implies maybe you did a few test runs first and tweaked some things. True? In any case, the first thing I'd try is removing config.cache and starting with ./configure again. The other thing I'd try is "gcc --verbose" and make sure the compiler has been built for Solaris 2.6. If none of that helps, take a look at config.log and see why the locking tests are failing. Please note that I am doing the build from "my" account which is the member of a few nice unix "groups" but is not the root account nor especially privileged. That's a good plan. Brian John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
