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:monitor AT oops.co DOT at
|
