QRecall Community Forum
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Top Downloads] Top Downloads   [Groups] Back to home page 
[Register] Register /  [Login] Login 

Checksum Error on Compact RSS feed
Forum Index » Beta Version
Author Message
Gary K. Griffey


Joined: Mar 21, 2009
Messages: 156
Offline
James,

I created a new archive and performed a capture action of a single folder. The capture completed OK. Next, I ran a Compact action...this failed....a re-index of the archive also failed. Repair of the archive failed too.

The report was sent.

Thanks,

GKG
James Bucanek


Joined: Feb 14, 2007
Messages: 1572
Offline
Gary,

I just replied to your diagnostic report before I saw this post. I'll summarize here for the benefit of others (I feel a FAQ coming on...).

Your compact failed when it encountered a damaged data record. There were actually two damaged data records. The repair action encountered the same damaged data; it erased these damaged records, along with the one file that used those records, and repaired the balance of the archive.

As always, I recommend repairing the volume containing the archive using Disk Utility (or your favorite volume repair program). Volume structure corruption can manifest itself as hardware problems.

The key point of interest is that the repair found the same damaged data reported by the compact. That indicates a permanent, rather than a transient, data error. If the location of the damaged data changed, or disappeared, the culprit would have been the hardware (controller, bus, RAM) between the data data on the drive and the CPU.

But since the bad data didn't move it either indicates a media failure (good data that went bad on the drive's surface), or a transient data error when the data was written (bad data preserved on a good surface).

One simply way to diagnose these problems it to regularly verify the archive. If a verify fails, verify it again. If the error is consistent you have a permanent error possibly indicating failing media. If, however, the error moves (or disappears) you have a transient error. This could be a problem with the bus, controllers, or even RAM. Try switching ports, changing cables, changing drive enclosures, or testing your RAM.

- QRecall Development -
[Email]
Gary K. Griffey


Joined: Mar 21, 2009
Messages: 156
Offline
James,

Thanks for the info. This Capture, Compact, Repair, etc., was run on a brand new Mac mini server with dual internal drives. The archive was stored on the second internal drive...not that it could not be simply a new drive that is bad...but I think the chances are low. I did run Disk Utility on the drive and it came back OK.

I will attempt the capture again...and this time, I will run a Verify action before running the Compact action. I just seem to remember that there was a bug with the Compact action a while back...but I have not seen it recently. I thought this may be a new "strain".

Thanks,

GKG
James Bucanek


Joined: Feb 14, 2007
Messages: 1572
Offline
Gary K. Griffey wrote:The archive was stored on the second internal drive...not that it could not be simply a new drive that is bad...but I think the chances are low.

There are two times that electronics fail: when you open the box, and five years from now.

I just seem to remember that there was a bug with the Compact action a while back...but I have not seen it recently.

That bug is still on my to-fix list, but this wasn't it.

- QRecall Development -
[Email]
Gary K. Griffey


Joined: Mar 21, 2009
Messages: 156
Offline
I agree about the failures...can happen anytime...

One question though...if a data read or write error occurred on the original Capture...the Capture would have failed, correct?

In other words, if the folder being captured (on internal drive #1) OR the archive being written to (on internal drive #2) was not read/written normally...the Capture would have flagged the error.

Thanks,

GKG
James Bucanek


Joined: Feb 14, 2007
Messages: 1572
Offline
Gary K. Griffey wrote:One question though...if a data read or write error occurred on the original Capture...the Capture would have failed, correct?

Not necessarily. When QRecall writes data, and the OS says the operation was successful, it takes the OS at its word. Data, however, could have been corrupted on it way to the drive (which the OS can't/won't detect), or the data could later get corrupted on the volume. Neither of these problems will be detected by QRecall until it reads that data back again—thus, the suggestion for the verify.

A feature, suggested by another user, that's currently on the to-do list for a future version of QRecall is to immediately re-read all of the data written during a capture to ensure that it wasn't corrupted.

- QRecall Development -
[Email]
Gary K. Griffey


Joined: Mar 21, 2009
Messages: 156
Offline
Ok...that makes sense....

I will retry the capture and immediately verify...

Thanks,

GKG
Gary K. Griffey


Joined: Mar 21, 2009
Messages: 156
Offline
James,

Just a follow-up on this...I recreated the archive and have run three subsequent capture/compact/verify actions and they are now running ok.

I am not sure what occurred on the first error...but the issue is no longer present.

Thanks for you feedback...if any other issues occur I will let you know.

At this point...I am seeing no issues with beta 54.

GKG

 
Forum Index » Beta Version
Go to:   
Mobile view
Powered by JForum 2.8.2 © 2022 JForum Team • Maintained by Andowson Chang and Ulf Dittmer