Linc Davis wrote:
I always used DiskWarrior after major update and always no trouble.
The trouble is that you're at least $100 poorer (maybe a lot more if you paid for "upgrades") with nothing to show for it. Not to mention the time you've wasted.
100 dollars is not much and it only take like 10 minits. restore can take hours. so it is not a hassle and i feel it is good for my system and hardly ever any problems.
I had sent SuperDuper an email including the KP log; here is what I got this morning:
There is absolutely nothing wrong with SuperDuper! under Lion. A kernel panic is due to system-level (low-level, kernel) issues with either I/O or other items. You'd need to investigate the actual panic report to understand what's going on...but my guess was drive problems utterly unrelated to what program copied.
He may be correct; however, since the KP only happens after having used SD! and then using DW, I'm not sure he is. So, I won't be using SD! again for a while and wait to hear from Alsoft.
When you hear from Alsoft, please ask why it is that Disk Warrior always finds "corruption" of your volume directories. Also ask why millions of other Mac users, including me, who have never used Disk Warrior and must therefore have even worse "corruption" than you do, don't seem to notice. Finally, if there's any gain in performance from fixing the "corruption," ask them to quantify it and support their claim with test results. They should be more than willing to provide all that information, considering how much money they're asking for their product. And I want to know what I'm missing. Who knows, maybe I'll change my mind about Disk Warrior and start using it myself. Thanks in advance.
Okay, so if he is:
1. why would it only happen after having used SD > DW (and not after using CCC > DW)?
2. and, what could/should I be doing to prevent future KP's?
FWIW, I will ask them about the directory corruption - that was on my list - because I find it odd having created a brand new clone on an empty partition that I wouldn't have a "perfect" system on that partition.
1: That's a question about the internals of DW. CCC is a wrapper for rsync, while SD is proprietary. Presumably, they leave the volume catalog in a different state. One of them triggers a bug in DW, the other doesn't.
2: Not wasting your time with DW.
By the way, DW is not detecting corruption in your volume directory. It's detecting what Alsoft considers to be "fragmentation" of a certain data structure in the HFS directory (the catalog b-tree.) That condition is a completely normal and inevitable result of using the filesystem. So the problem that DW is fixing is not a problem at all. I recall that, years ago, Alsoft used to claim in its marketing material that there was a performance gain from "defragmenting" the b-tree. It no longer makes that claim on its website, perhaps for fear of being sued for false advertising.
As I said is each to own. Lots say repair permissions for this and that especially after updates. DW is good and lots use it. Doesn't always find corrupt volumes like you say. You hate it. I hate doing TM backups to same effect takes too long. I was just telling op that DW 4.4 work fine on 10,7,3 did not want a fight over what software you like and what I like.
Please do trust the advice given by the developer of SuperDuper!.
Before I got to that quote on page two … reading page one of this topic …
In exceptional circumstances I might expect DiskWarrior to crash, but I doubt that DiskWarrior could cause a kernel panic.
For SuperDuper! I have even greater confidence that it should never cause a kernel panic.
Maybe off-topic from the symptoms described by babowa, here's the beginning of something that I'll feed through Apple Bug Reporter:
2012-02-02 09:49:54 kernel panic — Safari in foreground, VirtualBoxVM with Lion guest in background, IOHIDFamily, IOBluetoothFamily, IOBluetoothHIDDriver and AppleBluetoothMultitouch in backtrace, last loaded kext: IOAVBFamily, last unloaded kext: IOEthernetAVBController
In both my case and babowa's case, the last loaded kext is:
This need not indicate an issue with that kext, but it's a starting point — and the advice from the developer of SuperDuper! is a most valuable complement.
With attention to my file
I find it most unusual to have that combination of Apple extensions alone in the backtrace, last loaded and last unloaded areas.
There's a known minor issue with at least one of the three drives that I usually have on the FireWire bus of my MacBookPro5,2. Not an issue that I would expect to cause a kernel panic of this nature, but I keep an open mind. (I use this drive with its known issue for test purposes, not for data that's irreplaceable.)
Readers other than babowa, please note that I do not seek community help for my own issue. It's to be fed to Apple, and it should not be confused with babowa's case.
I might not revisit this topic. babowa, good luck!
> If a 35% + directory corruption is reported …
Those percentages given by DiskWarrior are measures of order within a directory. Not corruption.
Included with modern versions of Mac OS X, a command line utility can recreate — from an attribute B-tree and from a catalog B-tree that are without corruption — directories that are orderly. This is off-topic from any kernel panic, I recommend a visit to Ask Different. If the answer is not there already, ask the question and I'll pick it up in due course.
Here is an update:
Got a reply from Alsoft - they want me to do a PRAM reset:
This looks like a memory issue where a set of numbers is being improperly replayed. One of the key places to see this is:
>> Interval Since Last Panic Report: -8 sec
Minus eight seconds? Definitely not right.
Reset the computer's PRAM by holding down Command (Apple), Option, "P", and "R" keys while starting your machine. Continue to hold these keys until the computer makes the Startup chime three times.
Then, start up the computer from the DiskWarrior disc and run DiskWarrior again. What is the result?
And, as for the question re. a 35+% of directory:
The high percentage is usual and normal for a new operating system installation as the operating system and/or cloning software process does no optimization of the directory.
I'm certainly about as far from being an expert on this as one could be, but that strikes me as questionable. Using (maybe the wrong) logic, it would seem to me that if you write to a blank drive, it should be all neat and tidy when finished? Not haphazardly all over the place?
>> new operating system installation
Two key help pages from Apple:
- Mac OS X 10.7 Help: Reinstall Mac OS X, which includes a link to
- Mac OS X 10.7 Help: Erase and reinstall Mac OS X.
From an iDefrag perspective:
- reinstall will result in a layout of files that is less optimal than layout from a first install
- erase and reinstall will result in a relatively optimal layout of files.
With an erased volume, using any third party approach to write files might be less optimal than the routines provided by Apple. An exception is block-level cloning, which includes cloning the layout (without regard to optimisation).
Whilst layout of files may be sub-optimal, at the same time all three of the following may be optimal:
- attribute B-tree
- catalog B-tree
- extents B-tree
babowa, I'll seek answers for you in Ask Different …