stwobie Posted November 15, 2009 Report Share Posted November 15, 2009 I just upgraded to Retro 8 server. Have discovered that it no longer allows the hardware compression to occur on my LIB-81 AIT 3ex tape library. This is definitely an issue since upgrading to 8.1 (662). The tapes are identified at having only 144GB available. I ran the backup and sure enough, after only 423GB (3 tapes) it wanted a new tape to backup the remaining 100GB. The tapes have a max capacity of 390GB. And yes I do know that image/video files do not compress much at all, if any. But here is the kicker in Retro 6.1, it only took 2 tapes to backup the same amount of data just last weekend. Anyone else seen this and come up with a solution? As it is the weekend, I will have to wait till Monday to follow up with EMC and see what they can tell me. Quote Link to comment Share on other sites More sharing options...
Mayoff Posted November 15, 2009 Report Share Posted November 15, 2009 Retrospect will show an incorrect estimated capacity for the tape drive, but will continue writing until the hardware tells us the tape is full. Hardware compression is handled by the hardware and outside of Retrospect's control. Quote Link to comment Share on other sites More sharing options...
stwobie Posted November 16, 2009 Author Report Share Posted November 16, 2009 (edited) Although I know Retrospect has no direct control on the device as far as whether it uses compression or not, at the beginning of my cycle (1st weekend in November) in Retro 6, the same backup was fitting on 3 tapes. Now it does not in Retro 8. Something is not right. To satisfy my curiosity I reran my last cycle in 6. And sure enough, it fit on 3 Tapes. Exact same amount of data. Retro 8 requires 4 tapes. Something has changed. I will contact Retrospect and see what they have to say. I'm also looking into any firmware updates for the LIB-81 that might make a difference. Thanks for your response. Edited November 16, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 16, 2009 Report Share Posted November 16, 2009 Hardware compression is handled by the hardware and outside of Retrospect's control. That's not quite true, Robin. The software has to set the bit to cause the hardware to do the compression, and may not be doing so. But that may not be the issue in this case. Although I know Retrospect has no direct control on the device as far as whether it uses compression or not, at the beginning of my cycle (1st weekend in November) in Retro 6, the same backup was fitting on 3 tapes. Now it does not in Retro 8. Retrospect 8 is very immature and is slow. If Retrospect 8 cannot keep the data pipe full, the hardware will increase the inter-block gaps so as to avoid "backhitching", where the tape drive has to write an EOT mark, then rewind back a few blocks and get a running start to write the next block. That causes excessive tape wear and greatly increases the backup time. It may be that the inter-block gaps are increasing to the point that not as much data can be stored on the tape. Retrospect 6 is very mature, and is able to keep the data pipe filled. Another issue may be your processor architecture. You have not provided any information on what type of Macintosh computer you have or its architecture (PowerPC or Intel). A design decision was made with Retrospect 8 to keep the media sets in Intel (little-endian) format rather than PowerPC (big endian) format. When Retrospect 8 is run on a PowerPC, a lot of time is spent swapping the bytes back and forth from one format to the other. That byte swapping did not occur in Retrospect 6, which causes additional difficulty in Retrospect 8 on a PowerPC when trying to keep the data pipe filled to the tape. Russ Quote Link to comment Share on other sites More sharing options...
stwobie Posted November 17, 2009 Author Report Share Posted November 17, 2009 An update: I rebooted the server. And rebuilt my script, media set...etc. Now 1 tape is seen with 289GB available, the other 2 are seen with only 144GB. We're closer, but still trying to figure it out. I've spoken to EMC and Sony on this issue. EMC said talk to Sony, Sony called ME, and was very helpful. Did some read and write tests with and without compression. All looks good from their end. It is definitely a Retrospect 8 issue. I truly agree with Russ, Retro 8 is in it's infancy. But boy do I hate being a Beta tester for EMC. I will continue to pursue this. Thanks for your reply's. Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 17, 2009 Report Share Posted November 17, 2009 Remaining tape capacity is merely a guess, and should not be trusted. Retrospect writes until it hits EOT. Another issue may be your processor architecture. You have not provided any information on what type of Macintosh computer you have or its architecture (PowerPC or Intel). Some information might be helpful. Russ Quote Link to comment Share on other sites More sharing options...
stwobie Posted November 18, 2009 Author Report Share Posted November 18, 2009 Russ, It is an Intel Xserve. In all the years of working with Retrospect, since around 1996, I have never seen it fail to be reasonably close on tape capacity. It was never perfect, but it was also never this bad. This just gets more and more interesting. Remember how I was able to get it to see one tape as 289GB in size, the other 2 as 144GB in size. When my backup ran, it put 209GB on the first tape, 104GB on the second tape, then asked for a new tape. Even though there was a 3rd tape in the set with 144GB available. I truly think the driver is not communicating correctly with the device. Sony thinks the same thing. And an interesting comment by Scott from EMC was that the Driver is exactly the same as before, merely ported to the Intel processor set. And the results could potentially vary. Which in my opinion means that though they rewrote 8.1 from the ground up, they kept the drivers pretty much the same, and there may be some bugginess. Not good for my situation. So now I am trying long erases on the media, hoping beyond hope that Retrospect 8 will at least work with all 3 tapes in the set. Meanwhile, I will be getting back on the phone to EMC to see what they have to say. Quote Link to comment Share on other sites More sharing options...
stwobie Posted November 18, 2009 Author Report Share Posted November 18, 2009 Russ, Just got off the phone with EMC. This is a bug they have encountered. I will be sending them logs. I will get back to this forum if it is fixed. But for now, I have to collect some data, send it off, and wait. Aaron Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 18, 2009 Report Share Posted November 18, 2009 Ok, sounds like you are on the right track. Because you are running native on an Intel xServe, you shouldn't have the byte-swapping slowdown or PPC-specific bugs, so you are chasing something else other than big inter-block gaps. Just as an observation, it's interesting that the capacities, etc., that you are seeing on the second and third tapes is roughly half that of the first tape, which almost leads one to believe that compression might be turned off after the first tape, or perhaps the drive is operating in some sort of a backward compatibility mode for an earlier AIT version with half the density. Again, this could be a miscommunication with the drive, etc. And an interesting comment by Scott from EMC was that the Driver is exactly the same as before, merely ported to the Intel processor set. And the results could potentially vary. Which in my opinion means that though they rewrote 8.1 from the ground up, they kept the drivers pretty much the same, and there may be some bugginess. Not good for my situation. No, it's a "good thing" that the drivers were ported. That means that they are mature, which is especially important in hard-to-test error recovery routines. The potential problem, though, is if they were "merely" ported. Stuff that touches hardware is byte-order and bit-order sensitive. Been there, done that. It may be that some device-dependent data structure was not ported correctly, and it might be a compiler issue (different compilers lay out data structures differently, and Retrospect 8 isn't using the same compiler / tool set as Retrospect 6; that's one of the main reasons that the code base had to change rather than a simple warm-over). Further, some compilers can re-order the code execution order as optimization is done, which can be wrong for low-level hardware-dependent code. However, I would have thought that issues like this would have been caught in testing, if any testing / QA was done. Please follow up after you figure out the solution so that the rest of us can know. Russ Quote Link to comment Share on other sites More sharing options...
stwobie Posted November 18, 2009 Author Report Share Posted November 18, 2009 Russ, Will do. I am collecting data as we speak. Keith from ECM was very helpful in addressing the fact that this is more than likely a bug. He mentioned he had another client with a very similar issue. I am very surprised it has not come up before, but that's what troubleshooting is all about. Getting to the heart of the matter. Aaron Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.