mhVTL 1.5-4 exporting via FC to a AS400

classic Classic list List threaded Threaded
58 messages Options
123
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Hello,

Please find the output for the closed-source vtl next:

[root@vtl ~]# bash -x status
+ mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN
+ printf '\x00\x00\x48\x10\x00\x00\x00\x08\x44\x00\x00\x00\x00\x00\x00\x00'
+ printf '\x10\x0e\x00\x00\x00\x00\x00\x64\x40\x00\x18\x00\x00\x00\x00\x00'
+ sg_raw -i as400_mode_select -s 32 /dev/sg1 55 10 00 00 00 00 00 00 20 00
SCSI Status: Good

+ mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x46 (LTO-4).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Best regards,
Nuno Fernandes
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
In reply to this post by Mark Harvey
Hello Mark,

Were you able to work out the patch?

Best regards,
Nuno Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
No, but I did just have a 'light bulb' moment. i've got another report with failure working with Veeam. i think it's the same bug... I hope to have something tomorrow...

The more I think about it, the more the two issues align...

I've been going off on a wild goose chase... Sorry.

When reading the first block, a sense code is being returned incorrectly..

NetBackup always requests a 64k block, expecting a 1k block. So it expects a sense code.. But here, we are reading an exact block size and the initiator barfs when it sees the sense code.

Sent from my iPad

On Sep 7, 2016, at 18:30, npf [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:

Hello Mark,

Were you able to work out the patch?

Best regards,
Nuno Fernandes


To start a new topic under mhVTL - A Linux Virtual Tape Library, email [hidden email]
To unsubscribe from mhVTL - A Linux Virtual Tape Library, click here.
NAML
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
OK, I've pushed out several patches to github - some queued for a little while.
Can you pull these latest changes and re-test at VERBOSE 3 pls. I'm reasonably sure I've got it (initialise SAM STATE on a rewind).
Sorry its taken so long for me to wake up to the actual problem.
Lets see what else the AS400 exposes :)
Regards from Australia
Mark Harvey
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Hello,

First of all, i'm sorry for the late reply. Working offsite.

I tried the new version and the results are same. I can start the drive but when i try to initialize the tape in the as400, the tape "changes" from a LTO-4 to a LTO-3 (but it doesn't report any errors in the initialize of the tape). When i try to save data to the tape, i get an error in the as400 reporting that the backup was unsuccessfull.

Please find the logs at http://pastebin.com/1aQvXWqx

Thanks,
Nuno Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
Thanks for the update. I'll check it out. 

Sent from my autocorrecting iPhone

On 20 Sep 2016, at 00:28, npf [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:

Hello,

First of all, i'm sorry for the late reply. Working offsite.

I tried the new version and the results are same. I can start the drive but when i try to initialize the tape in the as400, the tape "changes" from a LTO-4 to a LTO-3 (but it doesn't report any errors in the initialize of the tape). When i try to save data to the tape, i get an error in the as400 reporting that the backup was unsuccessfull.

Please find the logs at http://pastebin.com/1aQvXWqx

Thanks,
Nuno Fernandes


To start a new topic under mhVTL - A Linux Virtual Tape Library, email [hidden email]
To unsubscribe from mhVTL - A Linux Virtual Tape Library, click here.
NAML
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
In reply to this post by npf
Sorry - one more test.
I see a sequence of :

$ egrep "\*\*|logger" mhvtl_as400_logs_2016-09-20.txt
Sep 19 15:11:16 vtl -bash: (12340) [root.root] |.| logger "initialize the tape on the as400"
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (394) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (395) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_read_position(): READ POSITION (396) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (397) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (398) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (399) **
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (400) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_rewind(): REWINDING (401) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_log_sense(): LOG SENSE (402) ** :  Sequential Access Device Log page
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (403) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (404) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_read_position(): READ POSITION (405) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (406) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (407) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (408) **
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (409) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (410) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (411) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_read_position(): READ POSITION (412) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (413) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (414) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (415) **
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (416) **
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (417) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): MODE SELECT 10 (418) **
Sep 19 15:11:42 vtl vtltape[12047]: clear_compression_mode_pg(): *** Trace ***
Sep 19 15:11:42 vtl vtltape[12047]: ssc_write_filemarks(): WRITE 2 FILEMARKS (419) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_write_filemarks(): WRITE 0 FILEMARKS (420) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (421) ** : Yes
Sep 19 15:11:42 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (422) **
Sep 19 15:11:43 vtl vtltape[12047]: ssc_read_position(): READ POSITION (423) **
Sep 19 15:11:43 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (424) ** : Yes
Sep 19 15:11:43 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (425) **
Sep 19 15:11:43 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (426) **
Sep 19 15:11:43 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (427) **
Sep 19 15:11:43 vtl vtltape[12047]: ssc_rewind(): REWINDING (428) **
Sep 19 15:11:43 vtl vtltape[12047]: ssc_log_sense(): LOG SENSE (429) ** :  Sequential Access Device Log page


No where does this 'initialize the tape on the as400' actually write a block of data.
Just two filemarks.

Then, the verify attempts to read an 80 byte block - and fails as it encounters a filemark.
Sep 19 15:11:56 vtl -bash: (12340) [root.root] |.| logger "initialize the tape successfull. No errors reported"
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (434) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (435) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_read_position(): READ POSITION (436) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (437) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (438) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (439) **
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (440) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_rewind(): REWINDING (441) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_log_sense(): LOG SENSE (442) ** :  Sequential Access Device Log page
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (443) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (444) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_read_position(): READ POSITION (445) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (446) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (447) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (448) **
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (449) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (450) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (451) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_read_position(): READ POSITION (452) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (453) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (454) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (455) **
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (456) **
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (457) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_mode_select(): MODE SELECT 10 (458) **
Sep 19 15:22:10 vtl vtltape[12047]: clear_compression_mode_pg(): *** Trace ***
Sep 19 15:22:10 vtl vtltape[12047]: rw_6(): READ: 1 block of 80 bytes (459) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (460) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (461) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_read_position(): READ POSITION (462) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_tur(): Test Unit Ready (463) ** : Yes
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (464) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_report_density_support(): REPORT MOUNTED MEDIA DENSITY SUPPORT (465) **
Sep 19 15:22:10 vtl vtltape[12047]: spc_mode_sense(): MODE SENSE 10 (466) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_rewind(): REWINDING (467) **
Sep 19 15:22:10 vtl vtltape[12047]: ssc_log_sense(): LOG SENSE (468) ** :  Sequential Access Device Log page



The IBM Ultrium-4 SCSI spec says this about SILI bit being set and a variable block read:

If the Suppress Incorrect Length Indicator (SILI) field is 1 and the Fixed field is 0, the drive will do one of the following:

v Report Check Condition status for an incorrect length condition only if the overlength condition exists and the BLOCK LENGTH field in the mode parameter block descriptor is non-zero (see clause 8.3 in the SCSI-3 Stream Commands (SSC)).

v Not report Check Condition status if the only error is the underlength condition, or if the only error is the overlength condition and the BLOCK LENGTH field of the mode parameters block descriptor is 0.


However, it says nothing about "If the block doesn't exist and is a filemark instead"

Can I ask for a "dump_tape -f <barcode>" please - I'd like to confirm the 'tape format' does in fact only contain two filemarks.


Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
In reply to this post by npf
Re: LTO-4 vs LTO-3 post initialization:

Sep 19 15:11:42 vtl vtltape[12047]: CDB (418) (delay 5): 55 10 00 00 00 00 00 00 20 00
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): MODE SELECT 10 (418) **
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  Save Pages: 0, Page Format conforms to T10 standard
Sep 19 15:11:42 vtl vtltape[12047]: retrieve_CDB_data(): retrieving 32 bytes from kernel
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): count: 32, param header len: 8
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  00: 00 00 48 10  00 00 00 08  44 00 00 00  00 00 00 00
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): Mode Param header: Medium type 0x48, Device spec param 0x10, Blk Descr Len 0x08, Buff mode 1, Speed 0
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): Descriptor block: density code 0x44, No. of blocks 0x00, Block length 0x00
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  Page: 0x10, Page Len: 0x0e
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  00: 10 0e 00 00  00 00 00 64
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  08: 40 00 18 00  00 00
Sep 19 15:11:42 vtl vtltape[12047]: set_device_configuration():  Report Early Warning   : No
Sep 19 15:11:42 vtl vtltape[12047]: set_device_configuration():  Software Write Protect : No
Sep 19 15:11:42 vtl vtltape[12047]: set_device_configuration():  WORM Tamper Read Enable: Yes
Sep 19 15:11:42 vtl vtltape[12047]: set_device_configuration():  Setting device compression Algorithm
Sep 19 15:11:42 vtl vtltape[12047]: set_device_configuration():   Mode Select->Clearing compression
Sep 19 15:11:42 vtl vtltape[12047]: clear_ult_compression(): +++ Trace mode pages at 0x62c760 +++
Sep 19 15:11:42 vtl vtltape[12047]: clear_compression_mode_pg(): *** Trace ***
Sep 19 15:11:42 vtl vtltape[12047]: lookup_pcode(): Looking for: Page/subpage (0f/00)
Sep 19 15:11:42 vtl vtltape[12047]: lookup_pcode(): Found "Data Compression" -> Page/subpage (0f/00)
Sep 19 15:11:42 vtl vtltape[12047]: clear_compression_mode_pg(): l: 0x62c760, m: 0xa622c0, m->pcodePointer: 0xa62300
Sep 19 15:11:42 vtl vtltape[12047]: lookup_pcode(): Looking for: Page/subpage (10/00)
Sep 19 15:11:42 vtl vtltape[12047]: lookup_pcode(): Found "Device Configuration" -> Page/subpage (10/00)
Sep 19 15:11:42 vtl vtltape[12047]: clear_compression_mode_pg(): l: 0x62c760, m: 0xa62340, m->pcodePointer: 0xa62380
Sep 19 15:11:42 vtl vtltape[12047]: completeSCSICommand(): OP s/n: (418), sz: 32, sam_status: 0

The vtl is being sent a 'Mode Select' with the following fields set:



Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  00: 00 00 48 10  00 00 00 08  44 00 00 00  00 00 00 00
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): Mode Param header: Medium type 0x48, Device spec param 0x10, Blk Descr Len 0x08, Buff mode 1, Speed 0
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): Descriptor block: density code 0x44, No. of blocks 0x00, Block length 0x00

Where:
Byte 0 and 1 -> Mode Data Length => 00 00 -> i.e. No mode data, Just contains the Header and Mode Descriptor Block.
Byte 2 -> Medium type => 48
Byte 3 -> 01 -> Buffer mode
And the Block Descriptor Length is 00 08 (8 bytes)


So - it's a Ultrium 4 Data Medium.


Mode Block Descriptor looks like:
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select():  00: 00 00 48 10  00 00 00 08  44 00 00 00  00 00 00 00
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): Mode Param header: Medium type 0x48, Device spec param 0x10, Blk Descr Len 0x08, Buff mode 1, Speed 0
Sep 19 15:11:42 vtl vtltape[12047]: ssc_mode_select(): Descriptor block: density code 0x44, No. of blocks 0x00, Block length 0x00


Density code - 44 => which is defined in table 180 as 'Ultrium 3'



Which is what is being reported post 'drive initialization'
# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x44 (LTO-3).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN





On Tue, Sep 20, 2016 at 12:28 AM, npf [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:
Hello,

First of all, i'm sorry for the late reply. Working offsite.

I tried the new version and the results are same. I can start the drive but when i try to initialize the tape in the as400, the tape "changes" from a LTO-4 to a LTO-3 (but it doesn't report any errors in the initialize of the tape). When i try to save data to the tape, i get an error in the as400 reporting that the backup was unsuccessfull.

Please find the logs at http://pastebin.com/1aQvXWqx

Thanks,
Nuno Fernandes


To start a new topic under mhVTL - A Linux Virtual Tape Library, email [hidden email]
To unsubscribe from mhVTL - A Linux Virtual Tape Library, click here.
NAML

Regards from Australia
Mark Harvey
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
In reply to this post by Mark Harvey
Hello,

> Can I ask for a "dump_tape -f <barcode>" please - I'd like to confirm the 'tape format' does in fact only contain two filemarks.

Yes.. Here it is:

# dump_tape  -f N00001L4
Media density code: 0x46                                        
Media type code   : 0x08                                        
Media description : Ultrium 4/16T                                
Tape Capacity     : 838860800000 (781 GBytes)                    
Media type        : Normal data                                  
Media             : read-write                                  
Remaining Tape Capacity : 838860799920 (781 GBytes)              
Total num of filemarks: 2                                        
Hdr:         Filemark(03), sz             0, Blk No.: 0, data 0  
Hdr:         Filemark(03), sz             0, Blk No.: 1, data 0
Hdr:      End of Data(05), sz             0, Blk No.: 2, data 0

Best regards,
Nuno Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
Many thanks..

I'll run a similar sequence of commands to a real LTO-4 drive and see what it does (tomorrow)..

I'll also forward the test script so you can check against the commercial VTL if you feel like it :)

Sent from my iPad

On Sep 20, 2016, at 18:20, npf [via mhVTL - A Linux Virtual Tape Library] <[hidden email]> wrote:

Hello,

> Can I ask for a "dump_tape -f <barcode>" please - I'd like to confirm the 'tape format' does in fact only contain two filemarks.

Yes.. Here it is:

# dump_tape  -f N00001L4
Media density code: 0x46                                        
Media type code   : 0x08                                        
Media description : Ultrium 4/16T                                
Tape Capacity     : 838860800000 (781 GBytes)                    
Media type        : Normal data                                  
Media             : read-write                                  
Remaining Tape Capacity : 838860799920 (781 GBytes)              
Total num of filemarks: 2                                        
Hdr:         Filemark(03), sz             0, Blk No.: 0, data 0  
Hdr:         Filemark(03), sz             0, Blk No.: 1, data 0
Hdr:      End of Data(05), sz             0, Blk No.: 2, data 0

Best regards,
Nuno Fernandes


To start a new topic under mhVTL - A Linux Virtual Tape Library, email [hidden email]
To unsubscribe from mhVTL - A Linux Virtual Tape Library, click here.
NAML
Regards from Australia
Mark Harvey
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Hello,

> I'll also forward the test script so you can check against the commercial VTL if you feel like it :)

If you think that it will help, i'll gladly do it.

Do you know if there is something like a scsi "sniffer"? I would like to do the execute the commands on the as400 and the closed source vtl and check what is going on.

Best regards,
Nuno Fernandes
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Hello,

Did you have any time to check this? Is there anything i can do to help?
Do you think that remotely accessing the mhvtl server would help?

Best regards,
Nuno Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
Sorry - I've been away on leave.
Trying to catch up on my backlog of paid employment first.. Then onto the mhVTL. Hopefully something in the next couple of days.
Initial test (just before leave) against real hardware did not highlight anything out of the ordinary, however the lack of any 80 byte block of data suggests the error occurred during initialization rather than attempt to use the 'formatted' media.
Regards from Australia
Mark Harvey
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Hello Mark,

Hope you are doing well...  If there anything i can do to help, please tell me.

Best regards and thanks for all the support
Nuno Fernandes
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
In reply to this post by Mark Harvey
Hello Mark,

Did you have any time to check this?

Thanks,
Nuno Fernandes
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

Mark Harvey
Administrator
Hmm, yet another delay. Sorry.
Payed employment has been crazy over the last couple of weeks. Plus some building work going on at home has taken any spare time.
I have come to a bit of a road block at the moment and struggling to identify any real reason for the failure.

There is a 'tcopy' subdirectory along with the mhvtl source code. Can I ask you to:
$ cd mhvtl-1.5/tcopy
$ sudo make

And then use '/usr/bin/tcopy <src> <dest>' - where the source /dev/nst* is the commercial VTL and dest is the mhvtl with a tape loaded.

tcopy a 'initialised' tape (i.e. no backups or data written)
tcopy a 'tape with minimal data' - perhaps backup one file (obviously without any critical data)
Where dest is two different mhVTL tapes (one per test).
provide a copy of the virtual media so I can view/ analyse the format.
Or at a minimum a "dump_tape -f <barcode>" of each (if you have restrictions providing the actual virtual media files).
Regards from Australia
Mark Harvey
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Mark Harvey wrote
Hmm, yet another delay. Sorry.
Payed employment has been crazy over the last couple of weeks. Plus some building work going on at home has taken any spare time.
No problem.. Hope everything is going well.

Mark Harvey wrote
And then use '/usr/bin/tcopy <src> <dest>' - where the source /dev/nst* is the commercial VTL and dest is the mhvtl with a tape loaded.

tcopy a 'initialised' tape (i.e. no backups or data written)
tcopy a 'tape with minimal data' - perhaps backup one file (obviously without any critical data)
Where dest is two different mhVTL tapes (one per test).
provide a copy of the virtual media so I can view/ analyse the format.
Or at a minimum a "dump_tape -f <barcode>" of each (if you have restrictions providing the actual virtual media files).
Current configuration;
[root@vtl ~]# lsscsi -g
[2:0:0:0]    cd/dvd  HL-DT-ST DVD-ROM GDR8084N 3.00  /dev/sr0   /dev/sg0
[4:1:0:0]    mediumx IBM      3573-TL          4.02  /dev/sch1  /dev/sg4           <--- MHVTL
[4:1:0:1]    tape    IBM      ULT3580-TD4      252D  /dev/st1   /dev/sg3          <--- MHVTL
[15:0:0:0]   mediumx IBM      3573-TL          6.24  /dev/sch0  /dev/sg2          <--- Quadstor VTL
[16:0:0:0]   tape    IBM      ULT3580-TD4      D711  /dev/st0   /dev/sg1         <--- Quadstor VTL

QuadStor VTL
[root@vtl ~]# mtx -f /dev/sg2 status
  Storage Changer /dev/sg2:1 Drives, 24 Slots ( 4 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = M00001L4                        
      Storage Element 1:Empty
.......

MHVTL
[root@vtl ~]# mtx -f /dev/sg4 status
  Storage Changer /dev/sg4:1 Drives, 24 Slots ( 4 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = N00001L4                            
      Storage Element 1:Empty
      Storage Element 2:Full :VolumeTag=N00002L3                            
      Storage Element 3:Empty
.......

# Tape initialized in the AS400 box

Copy of the initialized tape from the Quadstor to MHVTL
[root@vtl ~]# tcopy /dev/st0 /dev/st1
file 0: block size 80: 1 records
file 0: eof after 1 records: 80 bytes
eot
total length: 80 bytes

Stop mhvtl and backup
[root@vtl ~]# /etc/init.d/mhvtl stop
[root@vtl ~]# cp -a /opt/mhvtl/50/N00001L4 /tmp/N00001L4-Initialized

Start again MHVL and load tape
[root@vtl ~]# /etc/init.d/mhvtl start
[root@vtl ~]# mtx -f /dev/sg4 load 1
[root@vtl ~]# mtx -f /dev/sg4 status
  Storage Changer /dev/sg4:1 Drives, 24 Slots ( 4 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = N00001L4                            
      Storage Element 1:Empty
      Storage Element 2:Full :VolumeTag=N00002L3                            
      Storage Element 3:Empty
.....

# Backup done in the AS400 to the same Quadstor tape

Copy again the tape from Quadstor to MHVTL
[root@vtl ~]# tcopy /dev/st0 /dev/st1
file 0: block size 80: 3 records
file 0: eof after 3 records: 240 bytes
file 1: block size 28672: 113 records
file 1: eof after 113 records: 3239936 bytes
file 2: block size 80: 2 records
file 2: eof after 2 records: 160 bytes
eot
total length: 3240336 bytes

Stop mhvtl and backup
[root@vtl ~]# /etc/init.d/mhvtl stop
[root@vtl ~]# cp -a /opt/mhvtl/50/N00001L4 /tmp/N00001L4-Savlib

Create TGZ to upload
[root@vtl ~]# cd /tmp/
[root@vtl tmp]# tar zcf mhvtl-saved.tar.gz N00001L4-*


Please find the file in http://downloads.clientes.eurotux.com/npf/mhvtl-saved.tar.gz

Hope it helps,
Best regards,
Nuno Fernandes
npf
Reply | Threaded
Open this post in threaded view
|

Re: mhVTL 1.5-4 exporting via FC to a AS400

npf
Hello Mark,

Hope you are doing well. Did you have any time to see this?
Anything i can do to help?

Best regards,
Nuno Fernandes
123