Dan Olsen
Forum Replies Created
-
Scratch that last message. Despite getting into BRU PE without the “non-authenticated mode” message after entering the correct password 4 times, it still appears that BRU PE is not actually authenticating.
Just ran an archive and then a restore of the same archive, and I’m still getting all of the “permission denied” warnings in the restore window. Damn.
-
Thanks Tim, I’m getting my tapes marked full early in BRU PE but I’ve heard of others in the business getting the same behavior with Archiware P5. Its very inconsistent and seems to come in waves. I only write archives from locally attached thunderbolt raids that can easily handle the speeds of 2x LTO-6 drives.
-
Updating this, saw in another thread that a user was able to authenticate after entering the same (denied) password multiple times. Lo and behold, after 4 denials, I’m able to authenticate (apparently) on the 5th try. Very strange. Hoping all of this gets sorted and we can have a stable, fully operational version soon…
-
And the lack of reliability continues. Had an 8TB archive job complete the write and get through 4.3TB of the verify, and all of a sudden one of the drives decides it doesn’t want to do its job anymore. Back to the revving up and verifying a tiny chunk of data, revving down to a halt. Up, down, up, down. This machine really just picks and chooses when it wants to work. Here’s a sound bite, you can hear the revving behind the fan noise and the noise of the other drive actually doing what its supposed to.
-
Not exactly the same, but similar sounds from a base-level perspective. When the drives are acting properly in the library, they make the same constant sound for sustained periods of time–many minutes straight if not longer. When they aren’t working properly, its very clear because the spinning/whining noise of productivity slows to a halt, sometimes makes the knocking/clacking sound which seems like something is physically repositioning, and then starts whining again before repeating the aforementioned events. Or, it’ll just keep whining up and down over periods of a few seconds without the clacking. That’s when its really reading/writing slowly.
It’s been working properly for the last two days but I’ll nab a sound recording next time it inevitably starts screwing up again. But yeah, similar but different noises.
-
That’s a good question James. I ditched archiving from anything except directly attached thunderbolt RAIDs to remove storage from the list of potential culprits.
I’m starting to agree more and more with David–the whole chain for tape storage is just unreliable, and for me it started with LTO-6 (and automation). I’ve done a lot of troubleshooting over the years but LTO takes the cake by a long shot. Currently listening to one of the drives revving up and down, write speed dropping well below that of the other drive, when all day yesterday the exact same configuration (same exact type of data on the same source drive) cruised right along and finished at top expected speed. I don’t know what else that kind of behavior could point to beyond an unreliable system at the core.
I’d love to be proven wrong but its been an almost daily battle for two years with nothing even resembling an explanation or solution.
-
Just went to restore files from an archive written without authenticating BRU PE, and I’m getting nailed with “can’t access for write: errno = 13, Permission Denied”.
Apparently BRU is just unable to set ownership and files can be restored, though.
-
Thanks Andy, just clarifying that the new build did not fix the permissions issue. I am still not able to authenticate.
The other two issues were also existent in 3.1.23, and I let TOLIS know. Unfortunately, zero of the three issues were fixed in the new build I was sent last week, even though it was specifically supposed to fix all of them…
-
Thank you David, I completely agree on the lack of reliability, which was a total shock after so many years of great performance from LTO-5. It has definitely been very frustrating and has eaten away at quite a bit of sleep over the last few years.
I’ve considered NL disk-based, but it would grow incredibly fast at our facility. If I had a functioning LTO system I’d write about 1PB of new data to tape each year. And the nature of our work requires us to constantly use footage going back many years (as well as for stock footage sales) so it is crucial that everything is archived safely.
If you are actually able to get media on to tape, its tough to argue that there is a safer method–I can’t recall more than a handful of issues ever restoring data, and they were all fixable (well, I’m starting to restore from our old SDLT tapes to bring them onto new tape, so maybe that isn’t completely accurate..but an issue for another day!)
James – I’m with you. Completely random success or failure, and have tried every configuration under the sun. H680, HighPoint 2722, mac mini, old mac pro, nMP, multiple versions of OS X, different SAS cables, etc. I’ll run a job once and it’ll have any of the issues mentioned in my previous post, abort and start over, run exactly the same job, everything constant, and have success. Verify stalls or is crawling, cancel, run it terminal, and its fine and runs at speed. Doesn’t make any sense at all!
-
Any luck on your end Andy?
Got a new build from TOLIS but didn’t fix the issue. Also I’m not getting any job progress information, and the “how many tapes” feature isn’t estimating correctly now (we have 2 LTO-6 drives)…yikes
