James Vorley
Forum Replies Created
-
Seeing same issue here – updated to 3.1.23 to fix the sudo restore bug but now just can’t authenticate.
For now I’m just clicking cancel and not authenticating. Only problem is some restores abort after hitting BRUMAXWARNINGS value due to permissions issues but BRUMAXWARNINGS value can be manually edited to a higher value.
Andy out of interest what is your autoloader hardware & software setup? Backup or Archive (or both)?
-
Ok, it sounds like our stopping/starting behaviours are very similar.
Right now we’re waiting for HPE to provide a solution but this is a very slow process. It was last November I first discussed the issue with TOLIS and about 4 weeks ago that HPE got involved.
What gets me is the randomness of the issue, it doesn’t always appear. And I will see wildly varying speeds when reverifying the same tape repeatedly: sometimes 180 MB/s for the full data set, sometimes as low as 30-40 MB/s.
Have also tried four different Macs (2x nMP, 2 x old Mac Pros) and two different HBAs (ATTO H680 and the Highpoint Rocketsor 6328 and all see the same issue.
So if you’re unlucky enough to end up with a drive like mine the standalone may not fix your issue.
-
To clarify – our drive is from TOLIS but the drive inside is HPE (I believe it’s only HPE and IBM that make drives LTO-6 drives).
So our support contact is TOLIS but they then deal with HPE as this is potentially a hardware fault with an HPE part.
When the drive is in “slow mode” it sounds like it is stopping and starting. The drive is quite whiny when in operation but I believe this is to be expected.
I’m curious as to exactly what issues you’ve had with the LTO-6 autoloader as this is what we’re looking to purchase shortly?
-
Using TOLIS LTO-6 standalone just now.
Initial results were positive but now seem to be experiencing randon slow read/verify times. TOLIS have acknowledged the issue but as drive is HPE we’re reliant on them diagnosing. Which hasn’t happened yet, even though it’s been 4 weeks. It seems to be a very slow process. L&TT tool showsservo framing errors and some other issues.
Looking to get an LTO-6 autoloader from TOLIS imminently for backup (rather than archive) workflow. But slightly reluctant if our standalone isn’t working properly.
-
Skipping authenticating worked a treat, thanks Tim.
On 10.10.5 here.
Cheers
James
-
Exact same behaviour here after updating.
Verifies still working from the command line.
-
BRU is superb.
It’s supposed to support single archives up to an exabyte in size.
I’ve been in your position before trying to troubleshoot issues between software, computer, HBA and LTO drive. It can be impossible to get to the bottom of an issue with each supplier blaming it on the other.
The cool thing about TOLIS is they supply both archiving hardware and software and know what works with what.
LTFS seems like a good idea long term due to the open source nature but tbh I would rather trust proven proprietary technology to safeguard my data.
As an aside, we had an issue with the way BRU was reading catalogs which resulted in BRU requesting the wrong volume of a spanned tape set. This was quickly patched by TOLIS once we flagged the issue. We’ve also seen occasionally slower restore/verify times. TOLIS have suggested this is due to memory fragmentation on our Mac.
Anyhow the CRC verification method used by BRU is great and helps me sleep at night!
-
I’m seeing what appears to be a similar issue intermittently. Did anyone ever get to the bottom of this?
For example 167 MB/s write but only 53 MB/s verify:
++++++++++++++++++++++++++++++++++
Last BRU PE Archive Execution summary:20170111 13:19:52|3855|root|[L163] START (r 18.1.0.25), CMD = '/usr/local/bin/bru -c -m -vvvvvvvvv -j -O -A -QB -f ntape0 -QX -L STV-6-0006 -'
20170111 13:19:52|3855|root|[L167] device = ntape0, buffer = 2048K bytes, media size = , archive id = 587630f80f0f, (Op)
20170111 17:25:28|3855|root|[L182] wrote 1108950016 blocks (2217900032 KBytes) on volume [1], 4:05:36, 150508 KB/sec
20170111 17:26:36|3855|root|[L165] FINISH - 0 warnings, 0 errors, exit code = 0
++++++++++++++++++++++++++++++++++
Last BRU PE Verify Execution summary:20170111 17:26:54|5487|user|[L163] START (r 18.1.0.25), CMD = '/usr/local/bin/bru -ivvvvjf ntape0'
20170111 17:26:56|5487|user|[L167] device = ntape0, buffer = 2048K bytes, media size = , archive id = 587630f80f0f, ()
20170112 05:09:51|5487|user|[L182] read 1108950016 blocks (2217900032 KBytes) on volume [1], 11:42:57, 52585 KB/sec
20170112 05:09:51|5487|user|[L165] FINISH - 0 warnings, 0 errors, exit code = 0release: 18.1
variant: 1.28
serial number:
bru id: mac-osx
config: Jul 27 2016 13:47:11
capabilities: PE TOOLS
archive: ntape0
buffer size: 2048k bytes
device table: /Library/Application Support/BRU PE/etc/brutab[ BRUTAB ]
incl/excl file: /Library/Application Support/BRU PE/etc/bruxpat[ BRUXPAT ]
max warnings: 1000 [ BRUMAXWARNINGS ]
max errors: 500 [ BRUMAXERRORS ]
copyright: Copyright (c) 1985-2016, TOLIS Group, Inc.
All Rights Reserved.The issue appears randomly and often not at all on the same data and tape set. When the issue appears it seems to be on restore and verify operations.
I had the issue disappear for days and ~20 TB of read operations, then randomly reappear.
System is Tolis Argest LTO-6 (HP drive), ATTO H680, Early 2008 MacPro, OS X 10.10.5. I have also tested on an early 2013 Mac Pro with HighPoint RocketStor 6328 and see the same thing.
When the system is in whatever mode it gets in to that results in slow read/verify times if I switch to demos of other LTO software (YoYotta, PreRoll Post) I still see the slow read/verify times.
TOLIS are suggesting possibly the Mac’s memory was fragmented at the time of that job resulting in lots of small memory reads during the tape operation. But a reboot doesn’t always seem to fix the problem. All I’m running on my system apart from BRU is Media Encoder which is used a handful of times a day for the odd transcode of ~ 1 minute long commercials.
TOLIS also got me to export an L&TT support ticket which didn’t show any hardware faults with the drive.
After previous nightmare issues with LTO (a hand-me-down NovaBackup and LTO-4 system) this system is *almost* perfect, but would love to get to the bottom of these random slow read times.