Amanda-Users

estimation is _very slow_ and hangs.

2004-10-20 06:03:26
Subject: estimation is _very slow_ and hangs.
From: Iulian Topliceanu <iulian.topliceanu AT net-m DOT de>
To: amanda-users AT amanda DOT org
Date: Wed, 20 Oct 2004 11:51:46 +0200
Hi,

I had amanda running in the same configuration as now, for over 4 months without any major problem.

After migrating the filesystem from XFS to EXT3 everything is a mess.

The biggest problem I have is with this volume.

/dev/vol0/mailspool1  212G   37G  175G  18% /var/spool/mail

It might be 212 GB big but the space used is only 37 GB and it was always around 37 GB, the only thing that haschanged is that the disk size has been increased twice:

- first was 100 GB with XFS as fs and working fine
- then was increased to ~170 GB witch EXT3 fs and worked again fine.
- then was increased to 212 GB with EXT3 fs and does not work anymore.

Sometimes I get the error below and the disk doesn't get backuped

??error [/bin/tar got signal 13]? dumper: strange [missing size line from sendbackup] "

Either it simply hangs while doing the file size estimation without giving any error. Maybe I don't get any errors because I've increased the etimeout to 5600.

When looking at the process list on the backuped client, tar seems to be working fine:

4 D root 23034 16998 17 69 0 - 17887 down 02:44 ? 00:33:42 /bin/tar --create --file /dev/null --directory /var/spool/mail --one-file-system --listed-incremental /var/lib/amanda/gnutar-lists/baal_var_spool_mail_1.new --sparse --ignore-failed-read --totals --exclude-from /tmp/amanda/sendsize._var_spool

I've started the backup last night at 21:30 PM, and the estimation process was still running at 10 AM. So almost 12 h for the estimation. This is happening only on one server. The others are doing fine and only because the /var/spool/mail disk.

sendsize.20041019212950.debug does not tell anything weird, at the time I stopped the backup process, tar was still running and the estimation was still on her way. But running damn slow.

As far as I see in sendsize.20041019212950.debug the transferrate for one 30 GB big volume was 2.1 MB/sec, what could cause this problem?

Would it help if I'd split the /var/spool/mail into little parts?

Does EXT3 have any problems in managing files bigger than 10 - 15 GB?

Ah, one more thing that might be important: all the acl's are via LDAP. But why didn't I have this problem again?

Sorry for the long post but I'm kind of confused and it's the third day without a mail backup.

Regards,
Iulian Topliceanu

Attachment: iulian.topliceanu.vcf
Description: Vcard

<Prev in Thread] Current Thread [Next in Thread>
  • estimation is _very slow_ and hangs., Iulian Topliceanu <=