Moving data dilemma?

ldmwndletsm

ADSM.ORG Senior Member
Joined
Oct 30, 2019
Messages
232
Reaction score
5
Points
0
PREDATAR Control23

We're in a bind. We need barcode labels, but we cannot get any more before we run out, and we don't have enough tapes to recycle until then. We do, however, have another collection of non-TSM tapes (same LTO generation) with all numeric barcodes, but we'd prefer not to use these barcode labels long term as they don't fit our sequencing. Since the internal label must match the barcode label, we cannot just swap the barcodes once we get some new ones. The only workaround that I can see would be to use these tapes short term, and then once we have the new barcodes we'd then have to move the data from any primary and copy pools with all numeric barcodes to other tapes with the "new" barcodes. That's not too gargantuan a task because it's our hope that that won't last too long, but it's still an aggravation to say the least. The previous "all numeric" barcoded tapes would then be ejected, their barcodes replaced, reloaded and put back into the scratch pool to be reused.

Anyway, does anyone see a potential problem (other than time) with this approach? Is there anything that I've overlooked here? All admonishments welcome, please.

One gotcha that I can see is that we'd have to be careful not to take a standard sequence barcoded tape off site too soon because it might have a spanning file that continues onto one of these all-numeric barcoded tapes or vice versa. When we go to move the data from one of these all-numeric barcoded tapes, what if it needed to read the beginning or end of a file that spanned to/from some tape with a normal sequence? Obviously, that tape would have to be in the library or on site. Is there a way to determine which tapes are required to do a move?
 
PREDATAR Control23

we'd prefer not to use these barcode labels long term as they don't fit our sequencing.
Why is the sequencing an issue? The server won't care that they are not sequential, they could all be random and the server would still be happy. I'm part OCD, so I can see how having all sequential would be nice, but it's certainly not a Spectrum Protect requirement.


In my opinion, the amount of work you outlined to change the labels in the future to match the sequencing are not worth the benefits. I'm still struggling to see what the benefits of following the sequence are other than esthetics.
 
PREDATAR Control23

One gotcha that I can see is that we'd have to be careful not to take a standard sequence barcoded tape off site too soon because it might have a spanning file that continues onto one of these all-numeric barcoded tapes or vice versa. When we go to move the data from one of these all-numeric barcoded tapes, what if it needed to read the beginning or end of a file that spanned to/from some tape with a normal sequence? Obviously, that tape would have to be in the library or on site. Is there a way to determine which tapes are required to do a move?
The server doesn't differentiate numerical from alphanumerical. It's just a series of alpha-numerical characters either way. If the tapes that you want to change the barcodes are primary tapes, they should be checked in already anyway, so the move data will happen without issues. If they are copy pool tapes, then no need to do a move data, just delete those copy pool tapes from the inventory, and run another backup stgpool to create new copy pool tapes to replace the delete ones. So, there's really no need to know if there are files spanning and on what tapes.

But, back to my initial question. Why do they need to be sequential? What's the technical requirement?
 
PREDATAR Control23

Why is the sequencing an issue? The server won't care that they are not sequential, they could all be random and the server would still be happy. I'm part OCD, so I can see how having all sequential would be nice, but it's certainly not a Spectrum Protect requirement.

Yes, I concur, but the issue is that we've always used tapes beginning with a specific character (always the same one) to indicate the type of data on the tape. I'm coming into this shop as a Johnny-come-lately, so this was all set up well before my entry into the TSM realm. The problem is that these other tapes do not have characters in their barcode labels. The problem is further compounded in that this is a very large library with thousands of slots and tapes, and there are other groups using it, so it's partitioned, and one of the other groups uses all numeric, while we preface all of ours with a given character, and another group uses a different character.

In my opinion, the amount of work you outlined to change the labels in the future to match the sequencing are not worth the benefits. I'm still struggling to see what the benefits of following the sequence are other than esthetics.

Yes, again, but it's more than just esthetics as noted above. It's come down to a choice between the all numeric or tapes from the other group, but our work is more aligned with the other group, so to avoid confusion, it was decided that the numeric would be preferable for now, if you had to pick, Call it a Hobson's choice.

The server doesn't differentiate numerical from alphanumerical. It's just a series of alpha-numerical characters either way. If the tapes that you want to change the barcodes are primary tapes, they should be checked in already anyway, so the move data will happen without issues.

Well, yes, but we also have a shortage of slots and will not be able to license more slots for a while (gee, I guess I left out a lot of details in my initial post. Sorry about that, but it was getting long, and well ...) so we need to remove some of these tapes to shelve then onsite. We're not using reclamation on that pool.

If they are copy pool tapes, then no need to do a move data, just delete those copy pool tapes from the inventory, and run another backup stgpool to create new copy pool tapes to replace the delete ones. So, there's really no need to know if there are files spanning and on what tapes.

Ah, right. I'd forgotten about that. Thank you. For the tapes in that pool, that will make things much simpler.

But, back to my initial question. Why do they need to be sequential? What's the technical requirement?

I do not believe that they need to be contiguous, but it's preferred that they be distinguishable from the tapes used by the other groups if one was, say, comparing two physical tapes side by side. Inventories and knowing what media generation is being used by whom (who, maybe? No, I think it's whom in this case?) only goes so far.

Again, your points are excellent, so it's like why is one standing outside in the cold rain? Why not go inside? If my answers were not satisfactory, I still appreciate your responses. Thank you. This helps. :)
 
PREDATAR Control23

Yes, I concur, but the issue is that we've always used tapes beginning with a specific character (always the same one) to indicate the type of data on the tape. I'm coming into this shop as a Johnny-come-lately, so this was all set up well before my entry into the TSM realm. The problem is that these other tapes do not have characters in their barcode labels. The problem is further compounded in that this is a very large library with thousands of slots and tapes, and there are other groups using it, so it's partitioned, and one of the other groups uses all numeric, while we preface all of ours with a given character, and another group uses a different character.
That makes sense. Might sound silly, could you put another marking your tapes to distinguish them from the other group's tapes?
Well, yes, but we also have a shortage of slots and will not be able to license more slots for a while (gee, I guess I left out a lot of details in my initial post. Sorry about that, but it was getting long, and well ...) so we need to remove some of these tapes to shelve then onsite. We're not using reclamation on that pool.
Not running reclamation makes your slot shortage worst, but you probably already know that.
 
PREDATAR Control23

That makes sense. Might sound silly, could you put another marking your tapes to distinguish them from the other group's tapes?

Well, ours (call us group one) are already distinguished from the other groups' tapes in that ours begins with a unique letter (same for all our tapes), while group two's tapes begin with a different letter (same for all their tapes) and group three uses all numeric. So, yes, we could add another unique character, or some such thing, but we can only do that on the new barcodes that we get, so until then, we have to make do with the few labels that we have remaining and then eke it out with some of the spare tapes that group three gave us as a temporary workaround until we can get the new labels. We could use tapes from group2 also, but, again, we work more closely with them so we're more concerned about confusion with their tapes.

I actually tried printing some barcodes as a solution for this mess, and I've had 100% success with that over the years but for a different library and manufacturer. The backup software was different, too, but the same type and generation of media (LTO; not that generation matters there as far as barcodes). But the samples that I printed were not recognized by this tape library. So many possible culprits there (vertical height of barcode, spacing, reflectivity ... you name it, so a hall of mirrors).

Not running reclamation makes your slot shortage worst, but you probably already know that.

Yes, but thanks for pointing that out. I'm ignorant of a lot of features in the product. The reason that we don't use it for this particular pool is because we don't want the data being moved around unnecessarily. This was a conscious choice with the caveat/sacrifice being more tape and slot usage.
 
PREDATAR Control23

Where I said "not that generation matters with barcodes", I meant that, yes, we use the trailing 'L#' identifier, in its own, trailing cell, to identify the media generation, e.g. L6, but the labels are all the same size and dimensions for LTO, natch, so once you have labels working for LTO6 then you just have to change the identifier (maybe the sequence, too, if you like) to move to LTO7, 8, etc., but as long as the equipment (robot or electronic eye/scanner) hasn't changed then all is well for you. Well, that experiment didn't work so hot in this case. My labels did not endear themselves to this other library.
 
Top