Hi, Gene, on Sonntag, 12. September 2004 at 18:15 you wrote to amanda-users:
GH> The / ext3 journaling died and made GH> the holding disk read-only, whether coincident with a momentary power GH> failure or not I don't know. There was one of the usual 2 second GH> glitches at some point while amdump was running, but I have a *large* GH> UPS, so normally the only effect is the advisory window that Bulldog GH> pops up all over the system. If it bothered the system otherwise, GH> this is a first... GH> The guilty kernel in case its a kernel problem, is 2.6.9-rc1-mm4. might be due to the rc-nature ... GH> Right now, amflush is running to clean up that mess, but gawd is it GH> slow! Its far worse than if everything was running in PIO mode, and GH> DMA is enabled for both disks. Something like 40-50k a second is GH> being written to the vtape right now, so the amflush run will be many GH> many hours. The drives are however, on the same cable. But with GH> DMA133 running on both drives, it seems to me I should be seeing >>20megs a second being moved from the holding disk on /dev/hda, GH> to /dev/hdb. Each by itself hdparm -Tt's at >50 megs/sec from the GH> disk surface. GH> Silly Q: Using the 'file:' system, should I even be running a holding GH> disk? I do that, although on a different partition on another hdd. The speed you mention seems to be related to some IDE-problem ... The usage of the holdingdisk brings you dump-parallelism, even with file: >>This worked out for quite a few people so far. GH> Who are rather quiet on this list I might point out. ;-) >>If you NEED this, let's look at the code. GH> I think the only thing that bothered me is the chg-disk's inability to GH> handle a slot number with a leading zero I am still not sure that this is the case. I haven't found the time yet to look at this in detail, but a quick comparison between the various changer-scripts did not show any specific reason why this should not work out. GH> , which simplified some of my GH> other support scripts that grab the current /usr/local/var/amanda GH> dir, the /usr/local/etc/amanda dir, smunch them up into a tarfile and GH> append them to the tape after amdump or amflush is done and the locks GH> released. That way I have a complete copy of the indice and config GH> dirs that made that 'tape' on that tape. Which seems like a heck of GH> a good idea for bare metal recoveries. We should "talk" about this in another thread once. Interesting .. GH> The rest of amanda has no GH> such trouble with the leading zeros in the tape labels etc. And GH> actually, I don't believe its the tape labels, but how the slot GH> numbers are translated and used internally since this concept of a GH> 'slot' seems to be a re-write just for the file: driver. Or, more GH> likely I never ran into it before since my mechanical changers only GH> had 4 slots, and now I have 30 virtuals. I believe the appropriate WV GH> vernacular phrase is damnifiknow. :-) GH> Should I move that drive to the slave position on the other cable to GH> get my transfer speeds back into this century? I'm not sure it will GH> reach though. Its quite a ways up the full tower to the dvd GH> burner, /dev/hdc. Actually, I considered buying one of those 5.25" GH> adaptors with the builtin fans ($40 USD at circuit city) as this GH> drive is running in the low 40's celcius according to smartctl. Never mind low 40s ... Having only Master-devices helps sometimes, as the Slave always brakes down things. Although the 40k you mentioned are way too slow even for a master-slave-config. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
