Media Sets Pencil/Remove Grayed Out

[ewoh24]

Hi-

 

I'm trying to edit and/or remove a member from a media set and both the pencil and the minus tabs are grayed out. This is a tape backup set. Any ideas?

 

Thanks.

[ewoh24]

Anyone? Any ideas? This is pretty frustrating...

[rhwalker]

Perhaps a screen shot would help.

 

Is this a password protected or encrypted media set? If so, have you authenticated first?

 

Wouldn't a manual be useful in such a situation? Too bad there is no manual.

 

Russ

[ewoh24]

Hi Russ,

 

Yes, a user manual would be insanely helpful!

 

Nope, not protected.

 

Is there a way to attach a screenshot? I have nothing to link to...but basically, in the members section in media sets the only clickable option is the plus sign. I have a member selected. The minus sign and edit symbol are completely grayed out.

 

Hope this clarifies a bit. Thanks.

[rhwalker]

Is there a way to attach a screenshot?

Yes. See this post:

Forum Attachment Rules Change

 

Russ

[ewoh24]

Here is the screen shot. Thanks again.

[ewoh24]

Any help?

[Maser]

I don't use tape (so I should probably shut up here), but isn't the concept of tape to use the tape so it fills?

 

So the ability to change the "capacity" of a tape isn't really something you can set -- because tape capacity would depend on the size of tape? Which Retrospect wouldn't know about?

 

Or am I missing something really obvious?

 

(Without having a tape device, I added a Tape media set -- and the pencil is greyed out here, too. I'm thinking this is intentional for tape, no?)

 

 

[CallMeDave]

'm trying to edit and/or remove a member from a media set and both the pencil and the minus tabs are grayed out.

 

As Steve says, you can't Edit the capacity of a tape; even if Retrospect new the length down to the last centimeter it wouldn't be able to correlate that to a specific amount of data. Tape capacity depends on many variables.

 

And you can't just remove a used Member of a Media Set; Retrospect needs to always maintain its existence in the Catalog.

 

What you _can_ do is mark the tape as lost, if your intention is to tell Retrospect that that tape's contents are no longer to be considered as safely stored away. Unless there is something keeping the "lost" checkbox from working, it sounds as if the program is behaving as intended.

 

Dave

[rhwalker]

Unless there is something keeping the "lost" checkbox from working, it sounds as if the program is behaving as intended.

Well, we don't know what was intended because there is no documentation. That's why I hesitated to answer once I saw the screen shot.

 

I do think that the interface could be MUCH clearer, and would have benefitted from some user feedback during design (if such a step did happen) from those who do backups on a production basis. It's possible that all of this, and the intended function of the +/- buttons, etc., is documented somewhere in a manual that may eventually be released.

 

Personally, I think that it might be just as reasonable to expect the "-" button to function as a "lost" button, and to expect the "pencil" button to function as a media set rename button (except, for those who understand the mechanics of tape labeling, it can't happen because the tape header - a/k/a/ member header - is always the first logical block on the tape after BOT, and you can't write in place for most current tape technologies - writing a block prior to logical EOT terminates the tape there, making all previously-existing following blocks unreadable).

 

Russ

[ewoh24]

But what is interesting in my case is Retrospect seems to working off of one tape only. If there's a Media Set with two tapes, it fills up one member entirely and then asks for media and the job won't complete even though the other tape has plenty of space. What's the point of a Media Set with multiple members if one tape fills and it won't move on to the next one? That's why I wanted to remove that one maxed out tape and tried to force it use the next one. Not good practice but I wanted to see if the script would then skip to the new member which, BTW the script is is set to do under the "Schedule" option in the script but it doesn't seem to make that happen.

[rhwalker]

But what is interesting in my case is Retrospect seems to working off of one tape only. If there's a Media Set with two tapes, it fills up one member entirely and then asks for media and the job won't complete even though the other tape has plenty of space. What's the point of a Media Set with multiple members if one tape fills and it won't move on to the next one? That's why I wanted to remove that one maxed out tape and tried to force it use the next one. Not good practice but I wanted to see if the script would then skip to the new member which, BTW the script is is set to do under the "Schedule" option in the script but it doesn't seem to make that happen.

Ok, then that seems to be a bug. Would have been nice to know the real underlying problem in your original post.

 

I suggest that you call Retrospect EMC Support and work with them on this. It doesn't seem like this is something that can be resolved in these user-to-user forums. Here's the link to contact information:

Contact EMC Retrospect Support

 

Russ

[ewoh24]

Thanks Russ. I didn't bring up what I was trying to accomplish because it didn't seem to me to matter, as the issue to me was an obvious option not working. That's where I figured the bug was. Thanks for all your help.

[CallMeDave]

If there's a Media Set with two tapes, it fills up one member entirely and then asks for media and the job won't complete even though the other tape has plenty of space.

 

How have you come to the conclusion that "the other tape has plenty of space?"

 

Your attached screen shot shows 2 Members in the "X Serve Daily" Media Set, the first with 374.8 GB used and the second with 235.3 GB used.

 

While it's reasonable to _desire_ the second tape to store as much data as the first, as I noted up-thread, tape capacity depends on many variables. Even though the "Space Free" column in the Members tap shows a positive integer, Retrospect really has no way of knowing how much free space there might be on a tape spool until (and here Russ is more knowledgeable then any other Forum member) it reads the EOT marker, at which point it requests a new tape.

 

I also note that barcodes are being used. I don't have any experience with barcoded tapes so I can't offer any Gut Feelings or insight other then to suggest their presence should be considered in the troubleshooting.

 

I wanted to see if the script would then skip to the new member which, BTW the script is is set to do under the "Schedule" option in the script but it doesn't seem to make that happen.

 

Could you provide a screen shot of the Scripts->Schedule tab?

 

I didn't bring up what I was trying to accomplish because it didn't seem to me to matter, as the issue to me was an obvious option not working.

 

The subject and content of the original post discussed only the pencil and minus icon, both of which seem to be working as expected and intended. If there's an issue with the Media action of your Schedule, that's only now being reported.

 

Steps to reproduce are always helpful (necessary) to move the online discussion forward.

 

 

Dave

[ewoh24]

Hi Dave. Thanks for your contributions.

 

The XServe Daily screenshot was just an example shot. I have four scripts. Attached is one with the tape space showing 0. The XServe Daily was fine and not the one I was trying to work with. Again, at the time I was focusing on just the grayed out icons as the issue.

 

I also attached a screenshot of the scheduling media action.

[rhwalker]

Retrospect really has no way of knowing how much free space there might be on a tape spool until (and here Russ is more knowledgeable then any other Forum member) it reads the EOT marker, at which point it requests a new tape.

I have never claimed to be more knowledgeable then (sic) any other Forum member on any subject, including tape. I have written a couple of unix tape drivers and have worked on some tape interface hardware (all in my distant youth), and we use tapes daily.

 

There are three types of EOT:

 

(1) the physical end-of-tape, where the strip of tape physically ends. You can't read or write to the physical end-of-tape because that would pull the tape off of the reel and cause grave disorder.

 

(2) the EOT sense strip - a metallic (foil) strip on the tape that is sensed, and which is at a defined distance from the physical end-of-tape. This strip is an "early warning" indicator to the driver that the physical end-of-tape is approaching, and that the driver had better stop writing soon and write the logical EOT marks before the tape comes off of the reel.

 

(3) logical EOT - tape blocks (of usually fixed size for a given tape) are separated by an inter-record gap. Each file (sequence of blocks) has its last block followed by a "file mark" - a special code / sequence of flux transitions that signals the logical EOF (end-of-file). When two EOFs occur in a row, that's the logical EOT.

 

So, while reading, the tape driver looks for the logical EOT to determine the end of tape, not the physical EOT strip, because the actual logical EOT can occur AFTER the physical EOT strip is sensed (see above). While writing, the tape driver looks for the physical EOT strip and starts to close things down.

 

Modern tape drives have read-after-write heads, and verify the data being written. If the data doesn't match, error recovery begins. The driver (and drive, sometimes it's done automatically) stops writing, spaces backwards a few blocks, spaces forward to where it began to write the last block (that didn't verify), lays down a larger inter-record gap (to erase over the bad spot), and tries again.

 

When Retrospect decides that a tape is giving errors to the point that it can't use the tape reliably, it will declare that the tape is "full" and put a logical EOT there (ending the tape), and request another. Well, that's what it did with past versions. We don't have a clue what it does or intends to do with Retrospect 8 because there is no documentation (Where the @#%& is my Retrospect 8 User's Guide?).

 

From looking at the "SCreenshot_2.jpg" picture, the numbers seem consistent but odd. Note that the "Capacity" and "Used" of the "xServe Share Weekly" media set is 750.7 GB, the sum of the "Space Used" numbers for the two tape members. So far, so good. The "Space Total" for both members is 765.7 GB, which, as we know, is just a fictitious guess (and, in the immature Retrospect 8 state, I suspect that default guesses like this may be suspect), and merely informational. But still, so far, so good.

 

There's no information in this thread as to what type of tapes these are, so I don't know whether the 765.7 GB number is realistic, but Retrospect doesn't use this number anyway (see discussion above).

 

Attached is one with the tape space showing 0. The XServe Daily was fine and not the one I was trying to work with. Again, at the time I was focusing on just the grayed out icons as the issue.

Looks to me like the second member may have gotten a tape error or detected an EOT strip at the 375.5 GB mark.

 

Is it possible that both of these tapes are really acting as 375 GB tapes rather than 765.7 GB tapes? One possibility is that Retrospect 8 isn't setting the density bits correctly (I know that this happens on VXA-3 drives if the tape came out of the box with a VXA-2 header - you will get 1/2 the expected capacity, and have to use Exabyte's vxatool utility to put down a VXA-3 header so that the full density can be used).

 

If so, that would make all of the numbers consistent. Nothing left on tape 2, the "Space Total" number is bogus, and the "Space Free" number for the first member is simply a bogus calculation (bogus "Space Total" minus "Space Used").

 

See if the above helps you investigate the matter.

 

Russ

[ewoh24]

Hi Russ,

 

It does appear that the tapes are not being compressed, even though I have both hardware and software compression enabled (could that be an issue)? I wonder why that is. Getting 800GB per tape would end my worries immediately.

 

Tied in with this issue is the "Needs Media" message that pops up in the middle of a backup. It has never worked for this issue (it has never worked period). No biggie if I could just browse to the other tape and kickstart the backup but it's like nothing was chosen, no errors, nothing. You point towards the tape but Retrospect keeps chugging along happily.

[rhwalker]

It does appear that the tapes are not being compressed, even though I have both hardware and software compression enabled (could that be an issue)?

Well, previous versions of Retrospect would ignore software compression if hardware compression was enabled. None of us have a clue how Retrospect 8 operates because there is no manual, but there are a lot of bugs.

Where the @#%& is my Retrospect 8 User's Guide? So, hard to tell intended operation from bugs. I would suggest, though, that you disable software compression so that you are just focusing on Retrospect's interpretation of one option, rather than the interpretation of the two.

 

I wonder why that is. Getting 800GB per tape would end my worries immediately.

Well, you are just going to have to investigate, and it's more than just a compression setting that is in play and could be causing the problem. I explained the VXA-2 / VXA-3 bug upthread above.

 

Compression applies a compression algorithm to the data, and is independent of tape density. There's a command or bit for most tape drives to cause them to go into compression mode. Perhaps your tape drive has some sort of an indicator or status page to tell you its current mode.

 

Density determines how close together the bits are on the tape (well, actually, how many bits per inch are stored - sometimes the encoding isn't that simple because multiple bits are stored at once), and is independent of compression.

 

When people started reporting issues with VXA-2 / VXA-3 tapes, those of us with such drives used Exabyte's vxatool to figure out what was happening. VXA-3 tapes use the same physical media as VXA-2, but are written at twice the density. The drive writes some header information at the beginning of the tape to indicate whether the tape is a VXA-2 or VXA-3 tape, and a VXA-3 drive can read/write in either format. The problem is that Retrospect, when writing to a truly "erased" tape (in contrast to one where Retrospect had written its tape header (with member and media set information, etc.), Retrospect was not writing in VXA-3 mode. A workaround was to "erase" the tapes using Exabyte's vxatool diagnostic utility so that they had the magic bits at the beginning to indicate that it was a VXA-3 tape, rather than a completely blank tape. Retrospect was then able to handle the tape. You may be having similar issues.

 

You need to investigate what is happening on your drive using tools other than Retrospect, such as diagnostics for the drive, etc. Figure out whether compression is enabled, figure out what density the tape is being written at.

 

You may want to work with Retrospect support to figure out what is happening. I've tried to point you in the right direction, but I don't have one of your drives (and, besides, I'm not motivated to figure out this bug that affects your drive but not mine).

 

Tied in with this issue is the "Needs Media" message that pops up in the middle of a backup. It has never worked for this issue (it has never worked period). No biggie if I could just browse to the other tape and kickstart the backup but it's like nothing was chosen, no errors, nothing. You point towards the tape but Retrospect keeps chugging along happily.

That's a completely different and unrelated issue. Besides, as indicated before, once you have moved to another member, there's no going back. Well, perhaps there is in Retrospect 8, but we don't know because there isn't a manual.

 

Did I mention that there isn't a manual?

 

Here's how to contact EMC Retrospect support:

Contact EMC Retrospect support

 

Russ