New Ranks & Badges For The Community!
Notice something different? The ranks and associated badges have gone "Star Fleet". See what they all mean HERE
Highlighted
Absent Member.
Absent Member.
1526 views

RHEL6.5 supports MTWEOFI

Hello,

 

RHEL6.5 will support MTWEOFI , release is due to Q4 2013.

 

so my big question is if Dataprotector can use MTWEOFI  out of the box or do we need

an update?

 

MTWEOFI is present within mainline kernel 2.6.37-rc1, maybe HP DP already supports this?

 

bye

,

Stefan

0 Likes
6 Replies
Highlighted
Absent Member.. Absent Member..
Absent Member..

Hi,

 

you need to open a acase combined with an Enhancement Request to get the answers you need.

 

Best regards

Daniel

-----------
Please assign Kudos - How to assign...
0 Likes
Highlighted
Absent Member.
Absent Member.

I agree with Daniel.  I was pretty sure that MTWEOFI was not officially supported, but I checked the Product Announcements for DP 6.2, 7.0 and 8.0, and found nothing that mentioned this.  This is probably going to require an Enhancement Request

 

You can avoid opening a case by submitting the Enhancement Request yourself from the URL

 

             http://support.openview.hp.com/support.jsp

 

This requires HP Passport to access.  Click on the Self-Solve tab, in the grey shaded area on the left, you will see 'Enhancement Requests', click on 'Submit an Enhancement Request'

0 Likes
Micro Focus Expert
Micro Focus Expert

I have collected some interesting facts regarding MTWEOFI and Data Protector. Please check my recent blog post for details.

Tape drive performance with MTWEOFI on Linux
http://www.syncer.de/?p=862

Please use the Accept Solution button next to my post and assign a KUDO (thumbs up icon) if this works for you.

Regards,
Sebastian Koehler

---
Please use the Like button below, if you find this post useful.
Highlighted
Absent Member.
Absent Member.

If you want to take advantage of all SCSI commands it's easier to set OB2FORCESCSI=ALL. In case of WFM(Write filemarks) it's only limited to that specific option.

Highlighted
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

Hi,


@Mass2 wrote:

If you want to take advantage of all SCSI commands it's easier to set OB2FORCESCSI=ALL. In case of WFM(Write filemarks) it's only limited to that specific option.


Is there any documentation available as to what OB2FORCESCSI is doing, what the options are and how they interact? I entirely missed the fact that MTWEOFI is finally supported by DP (was that really mentioned in the 9.05 release notes?) but stumbled upon it some weeks ago. Seeing that I'm running 9.08 and the MA in question is on CentOS 6.9 I thought I were good and applied the settings as proposed by Sebastian (with OB2FORCESCSI=WFM). My first test run of a copy to tape worked well.

It was only when the next copy tried to append to the tape so written that the brown stuff hit the cooling device. The session would run into

[Major] From: BMA@alucard.backup "MSL-DB-D1"  Time: 06.07.2017 09:45:28
[90:183] 	Cannot backspace block. (Details unknown.)

then declaring the tape poor and aborting. Of course, the next copy session will pull another tape, successfully write a session to it, only for the session following that again failing to append, wasting another medium. I managed to stop the madness after three tapes painted red, but only by removing the WFM enhancement options. A quick check of the CentOS Kernel source corresponding to the running version showed that MWEOFI is definitely there in st.c.

Later inspection of the affected tapes with mt(1) revealed them to be mostly Ok, they even verify good and turn green again - only to fail on another attempt to append to them. The culprit is they have exactly one extraneous file mark before EOD. So where a normal tape written by DP will end in EOF-EOD after the last non-empty read(2), my problem tapes ended EOF-EOF-EOD. Apparently the MA will wind the tape to EOD, than backspace a certain amount of files and expects to find the last written content there - which fails when there is an additional file to backspace over. I could even prove this theory by repairing the tapes so affected:

# mt -f $TAPE eod
# mt -f $TAPE status
# mt -f $TAPE bsf 2
# mt -f $TAPE status
# mt -f $TAPE weof
# mt -f $TAPE rewind
# mt -f $TAPE eod
# mt -f $TAPE status

After these steps, the tape now ends one file earlier (e.g. File number=84 where it was 85 in the first mt status) and DP can append to it again as usual (explicitly tested using preallocation).

So the question comes down to: Why is this happening? Would OB2FORCESCSI=ALL have prevented it? And where can I read about it?

TIA,
Andre.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Hi André,

please check my latest post on this topic. It seems there is a bug in the BMA in more current versions.

Unable to append tape with MTWEOFI enabled
http://www.syncer.de/?p=1039

Regards,
Sebastian Koehler

---
Please use the Like button below, if you find this post useful.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.