Re: amanda timeouts and weirdness solved!
--On Wednesday, August 24, 2005 10:11:04 -0600 Graeme Humphries [EMAIL PROTECTED] wrote: So, you guys may recall I was having problems with amcheck and amdump taking ridiculously long. Well, it turns out that because on that client box, there was a dead Samba mount. As you guys know, when there's a Samba mount that's timed out, or the remote machine is unavailable, any operation checking mounted partitions takes forever and eventually times out. So... what in Amanda is checking mounted partitions on every operation, and can we limit to only the partitions we're actually backing up? :) I don't think Amanda checks all your mounts. However, many filesystem operations 'stat' their way up the directory structure to /, and if you mount things directly in / (such as /remotedir) instead of down a level (/mnt/remotedir) many of those ops will hang if that mount is hung. Not sure if this even applies in your situation, it's just something I've observed with hung NFS mounts in /. Amanda does do a df of a couple of places (indexdir and tmp perhaps?) but I doubt those would hang unless they happened to be on your hung mount. Frank Graeme -- Graeme Humphries ([EMAIL PROTECTED]) (306) 955-7075 ext. 485 My views are not the views of my employers. -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: amanda timeouts and weirdness solved!
Frank Smith wrote: I don't think Amanda checks all your mounts. However, many filesystem operations 'stat' their way up the directory structure to /, and if you mount things directly in / (such as /remotedir) instead of down a level (/mnt/remotedir) many of those ops will hang if that mount is hung. Not sure if this even applies in your situation, it's just something I've observed with hung NFS mounts in /. This particular case was mounted under /tmp/somedir, and amanda's set to backup / on that box, so that could be it. Amanda does do a df of a couple of places (indexdir and tmp perhaps?) but I doubt those would hang unless they happened to be on your hung mount. Doesn't df always scan all the mounted filesystems? Or can you restrict it? Graeme
Re: amanda timeouts and weirdness solved!
--On Wednesday, August 24, 2005 11:02:47 -0600 Graeme Humphries [EMAIL PROTECTED] wrote: Frank Smith wrote: I don't think Amanda checks all your mounts. However, many filesystem operations 'stat' their way up the directory structure to /, and if you mount things directly in / (such as /remotedir) instead of down a level (/mnt/remotedir) many of those ops will hang if that mount is hung. Not sure if this even applies in your situation, it's just something I've observed with hung NFS mounts in /. This particular case was mounted under /tmp/somedir, and amanda's set to backup / on that box, so that could be it. I think Paul's point is valid about tar's one-filesystem flag, I haven't tried it, but perhaps if you exclude ./tmp it won't stat /tmp/somedir. The real solution, of course, is to not have hung mounts ;-). Amanda does do a df of a couple of places (indexdir and tmp perhaps?) but I doubt those would hang unless they happened to be on your hung mount. Doesn't df always scan all the mounted filesystems? Or can you restrict it? If you call df with a filename or directory argument it only reports on the mount point containing it. Frank Graeme -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: amanda timeouts and weirdness solved!
Frank Smith wrote: I think Paul's point is valid about tar's one-filesystem flag, I haven't tried it, but perhaps if you exclude ./tmp it won't stat /tmp/somedir. The real solution, of course, is to not have hung mounts ;-). I agree. :) If you call df with a filename or directory argument it only reports on the mount point containing it. Ahhh.
