mhVTL returning empty data on filemarks

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

mhVTL returning empty data on filemarks

SteinnGaubert
Note: This is a new issue I've found with mhVTL - unrelated to another topic that I started earlier today.  Sorry for any confusion that causes.

I've found that when a read is request that is longer then the data remaining until a filemark (also end of tape I think), mhVTL correctly responds with the right amount of data but the entire read request is zero'd out!  On every physical drive I've ever seen, if there are 4 blocks of data until filemark and you try to read 8 blocks, the drive returns the 4 blocks and reports the filemark.  mhVTL is returning the correct number of blocks but the content is all zeros.

Here's a script to test it.  I ran it on a physical drive and mhVTL:
mt -f /dev/nst0 rewind
mt -f /dev/nst0 setblk 512
dd if=/dev/urandom of=/dev/nst0 bs=512 count=4 2> /dev/null
dd if=/dev/urandom of=/dev/nst0 bs=512 count=4 2> /dev/null
dd if=/dev/urandom of=/dev/nst0 bs=512 count=4 2> /dev/null
mt -f /dev/nst0 rewind
dd if=/dev/nst0 of=tmp.00512 bs=512
mt -f /dev/nst0 rewind
dd if=/dev/nst0 of=tmp.02048 bs=2048
mt -f /dev/nst0 rewind
dd if=/dev/nst0 of=tmp.04096 bs=4096
mt -f /dev/nst0 rewind
dd if=/dev/nst0 of=tmp.65536 bs=65536
md5sum tmp.*
rm tmp.*
On a physical drive all the reads return the same data:
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 0.0431069 s, 47.5 kB/s
1+0 records in
1+0 records out
2048 bytes (2.0 kB) copied, 0.027694 s, 74.0 kB/s
0+1 records in
0+1 records out
2048 bytes (2.0 kB) copied, 0.0297097 s, 68.9 kB/s
0+1 records in
0+1 records out
2048 bytes (2.0 kB) copied, 0.0267036 s, 76.7 kB/s
50e0878eb0b4b0cf3e5fb8565178f0fc  tmp.00512
50e0878eb0b4b0cf3e5fb8565178f0fc  tmp.02048
50e0878eb0b4b0cf3e5fb8565178f0fc  tmp.04096
50e0878eb0b4b0cf3e5fb8565178f0fc  tmp.65536
But on mhVTL:
4+0 records in
4+0 records out
2048 bytes (2.0 kB) copied, 0.0200586 s, 102 kB/s
1+0 records in
1+0 records out
2048 bytes (2.0 kB) copied, 0.00902042 s, 227 kB/s
0+1 records in
0+1 records out
2048 bytes (2.0 kB) copied, 0.00470582 s, 435 kB/s
0+1 records in
0+1 records out
2048 bytes (2.0 kB) copied, 0.00480621 s, 426 kB/s
950d2b5855c36a96544ad101bbf17700  tmp.00512
950d2b5855c36a96544ad101bbf17700  tmp.02048
c99a74c555371a433d121f551d6c6398  tmp.04096
c99a74c555371a433d121f551d6c6398  tmp.65536
You can't tell from the md5's but the 4096 and 65536 reads are all zero's.  mhVTL should be returning the actual data (and the filemark - which it does).

I know this is a contrived test case, but I hit a much more complex version of this issue when I was trying to figure out why a couple of backup packages were not working with mhVTL.  This is the simplest reproducible test case I could come up with.

I took a stab at trying to fix this but got completely lost in the code.  I'll still work away at it, but right now I'm pretty confused on how it all flows.

Thank you!
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL returning empty data on filemarks

Mark Harvey
Administrator

Many thanks for the bug report..

This is a rather nasty bug, but should be simple enough to fix.

Most backup software use variable block writes which probably explains why this has remained hidden for so long (or read one block at a time).

I'll be looking into both bug reports early next week.

Feel free in having a stab at fixing if you like - patches are always welcome :)
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL returning empty data on filemarks

SteinnGaubert
Something about mhVTL confuses me and I haven't been able to track down the bug.  Any ideas where to start?
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL returning empty data on filemarks

Mark Harvey
Administrator
I used the same set of cmds in your test script.

I end up with same md5sum for all 4 read results (same as your physical drive test)
Regards from Australia
Mark Harvey