On Wed, Sep 15, 2010 at 8:08 PM, Valeriu Mutu <vm...@pcbi.upenn.edu> wrote: > /dev/mapper/cronos-amanda-holdingdisk > 886G 116G 726G 14% /data3 > /dev/mapper/cronos-amanda-diskbuffer > 394G 199M 374G 1% /data4
350G seems a bit large for a disk buffer - what part size are you using? > When the problem re-occurs, I change the MTU to a different value: if it's > 9000bytes, I change it to 1500bytes, and vice-versa. > > Does anyone know why this happens? Why does Amanda become slow at reading > from the holding disk residing on an iSCSI volume? I don't know much about iSCSI, but as you know Amanda just accesses the disk via the normal filesystem, so I suspect that you could see a similar phenomenon with any application that is reading from or writing to the partition. Perhaps Amanda's not *writing* data very quickly at that point - maybe your tape drive is shoe-shining? Interrupting the connection by resetting the MTU (and I don't see why this would interrupt the connection..) would allow several layers of buffers to flush, resulting in a surge of read activity when connectivity is restored, until the buffers are again full. It sounds like there are some unresolved network issues with iSCSI, if the iptables is causing problems with multipathing. I would recommend taking a hard look with tcpdump to see what's going on. You'll always learn something! I've found some people who were complaining vociferously that Amanda's throughput "sucked", when in fact their network had a high packet loss rate because their server was hooked into a hub with a massive number of collisions. Hopefully your situation isn't quite that dire.. Dustin -- Open Source Storage Engineer http://www.zmanda.com
