On Fri, Apr 20, 2007 at 01:12:22PM -0400, Gene Heskett wrote:
> In watching the write traffic into /dev/hdd, where my vtapes are located, I'm
> seeing, particularly for the larger sized dle's, a write pattern that
> resembles a picket fence in the gkrellm display. I have 60 some GB of
> holding disk, the reserved is set for about 30%, and the largest dle is less
> than the size of a vtape as set in the tapetype. Total data is about 46GB.
>
> It seems to me that when a dle has been collected into the holding disk, then
> a taper should fire up and just dma the data from the holding disk to the
> vtape, but I'm seeing writes of less than 10KB, interspersed with 55MB,
> reported by the gkrellm utility display. hdparm says the disk is about a
> 75MB/Sec disk.
Unfortunately, it's not practically possible to "just dma the data"..
We looked into a few reasonably portable ways to get the kernel to
accelerate disk transfers (O_DIRECT, various madvise flags), and the
results were fairly inconclusive.
> How best can I troubleshoot this?
Well, first, you shouldn't expect to get anywhere near the platter speed
of your disk, particularly with ext3 or its brethren. I hear that XFS
is capable of higher speeds, but that's unconfirmed and I've never used
it. For ext3, somewhere around 40-50MB/s is probably the maximum sustained
write-only bandwidth you'll see (based on my experience).
You say that both your holding disk and your vtapes are on the same
drive. That means that reading from one and writing to the other
requires the drive to seek between the relevant files, which is going to
be *very* slow.
I'm not sure exactly what gkrellm is measuring (individual write() calls
or total writes over a certain period?). The two suggestions I have
are:
- use 'iostat' instead as a rough IO measurement tool
- annotate the amanda source to call dbprintf() at the relevant read()
and write() calls, along with the sizes requested and actually
performed.
I think the bottom line is: this might be an interesting exercise, but
will probably not lead to any substantial proposed changes in amanda.
Dustin
--
Dustin J. Mitchell
Storage Software Engineer, Zmanda, Inc.
http://www.zmanda.com/
|
