I've researched this problem and I've made some changes, but still my old iMac, yes old, has lately been taking a long time to start and shut down. I sit and watch the circular icon. Possibly I've also been getting the beach ball in the Finder more than I used to.

I have reset the PRAM, SMC, deleted unnecessary files, disabled login items, run the Onyx options, used Disk Utility, reinstalled OS 10.6.7, disabled and deleted fonts, stripped languages and architectures with Monolingual. I even disabled Dasboard via sudo, which did nothing. My hard drive has a 160 GB capacity and I've used almost 60 GB of it. That might be the most telling item, but there's a still a lot of space.

Helpful suggestions are welcome. Thanks.

You didn't mention SMART or running a surface scan. Have you tried either one (preferably both)?

Not a surface scan, just the initial scans by Onyx.

TechTool Pro can run a surface scan (which can take several hours). If you don't have it, there is a way to do it via Terminal but I don't remember the command.

I don't have time to hunt for it but I had a thread here awhile ago with a robust script for that

Jon…it may not be too long for deniro as his drive is only 160GB. I recently did a surface scan for a different issue and got it going in the evening, thinking it might be an overnight task. It was wrapped up in less than three hours on a 320 GB drive.

The drive was okay so I don't know if factors, like finding lots of bad sectors, will affect speed.

Finding bad sectors will materially effect the length of time it takes to do a surface scan. When a bad or marginal sector is found the drive tries several times to read the sector before it gives up and remaps it to a spare sector if there are any available on the drive.

Apple has deprecated the practice of defragmenting files and volumes in the more recent releases of OS X and most especially in the case of SSDs, but given the vintage of deniro's Mac and his OS X version, this is exactly the situation many of us routinely prevented with periodic file and volume defragmentation. TechTool Pro or Drive Genius both have reasonably safe and reliable defragmentation routines. Again given the vintage of deniro's Mac a rebuild/repair of the volume structure would not be amiss either. TechTool Pro, Drive Genius, or Disk Warrior would be the recommended tools for that, but even Disk Utility would be better than nothing. No matter which tool is chosen it would be important to have the version that is compatible with OS X 10.6.

Any reason you can't update to 10.6.8?

Have you got DiskWarrior for the directory? TechTool to optimize the drive?

Also, more RAM would help.

Sorry if all this is redundant info...

RAM is maxed out. I don't own Tech Tool or Disk Warrior, though I did in the distant past, and no intention of buying either.

I always had font problems in 10.6.8. Fonts looked jagged. I worked on that for a long time over years. I don't want to mess with it anymore.

There's a program called SMART Utility for $25. Anyone here think it's worth getting?

I ran the demo. It found no problems.

It found no problems, so it run it out, and then make a decision. (It seems to me like a lot of money for what I call "paranoia-ware".) Have you checked its reviews on MacUpdate...always worth a look?


Note: I didn't research whether the demo is restricted functionality.

(If you bought AppleCare with your iMac, the TechTool Deluxe disc that came with it can run a surface scan.)

As Joe has pointed out, many times, SMART is not the last word in testing a hard drive. A surface scan is much, much better. At any rate, Disk Utility can do SMART, albeit manually when you launch it. Simply select the disk in the DU window and the SMART status will appear in that window.

I can't tell whether SMART Utility does a TechToolPro quality S.M.A.R.T. test or not (Edit:) is just a GUI for DU's test. (I won't risk running my out of date version of TTP, but from memory I'll say that it reports on more criteria than are shown in the MU screenshot.)

And while a surface scan is, indeed, useful, it tests for something that S.M.A.R.T. does not test for, and more or less vice versa.

No, it doesn't. I don't see anything about SMART in Disk Utility.

DU has a different appearance in El Cap, compared to Snowy. If I recall correctly, you'll see SMART status at the bottom of the window. (Be sure that you have selected a drive in DU.)

That's right. I had to click on the other hard drive icon. There were two.

SMART status: Verified

The problem with SMART in general is each drive manufacturer sets it's own SMART parameter limits and they quite naturally set the limits very high to postpone declaring a failure as long as possible. Additionally each vendor determines what values to test.It is entirely possible, even likely, a drive may fail multiple parameters while the aggregate value still reports "Passed". In fact I have encountered that exact situation a few years ago. TechTool Pro is the only tool I am aware of that reports all of the individual SMART parameter values as well as the aggregate value.

Since the SMART standard has been around for a good while there is no reason the report from an older version of this TTP would create any problem. The only problem with out of date utilities is when and if you attempt to make repairs or changes using them on a more recent version of OS X.

I just ran TTP's SMART on my 1 TB Apple HDD, part of a fusion drive. The only questionable part is Temperature Changes (190), where the indicator is not quite in Fail territory but almost at the third line, but not in Fail territory.

Raw Read Error Rate (1) reads just to the right of the leftmost line, as does Seek Error Rate (7). Both are comfortably in the Pass region.

How do I interpret these results? All other parameters were perfect. TTP rates this overall as Pass.

EDIT: I just checked the Reports from TTP 8.03 and there is no difference in SMART when it was done in April, 2015 (when the computer was new). May I assume that this questionable result means nothing?

That was my gut feeling; thanks for confirming it. (I assume the same can be said of using an outdated version of TTP to run a surface scan.)

Since any repairs resulting from a surface scan would be the responsibility of the drive firmware it should be safe.

Again the principal danger occurs if out of date versions of DW, TTP, DG, or whatever attempts to make repairs or changes to the system — particularly to the file or volume structure. There are also potential problems with any test, repair, etc that uses command line utilities as those can and do change from OS X release to OS X release.

It's interesting that with all the discussion that's gone on here over many years about surface scans and zeroing all data to map out bad blocks I don't remember anybody ever having mentioned until very recently that bad blocks discovered during a scan are automatically mapped out.

If that's the case, and totally apart from its security functionality, zeroing either maps out bad blocks without your ever knowing they existed...bad idea, or is redundant because the bad blocks you know about from having run a scan have already been mapped out.

Zeroing is, of course, contraindicated with SSDs, but it now appears to have always been contraindicated, even with HDDs, without running a scan beforehand.

(Should this line of discussion have its own thread?)

Any time a drive encounters a bad block the firmware on the drive automatically remaps that block to an available spare sector on the drive. That happens in the normal course of writing to the drive. The critical factor in a surface scan is the discovery of NEW bad blocks which by definition would be data blocks that have gone bad since they were last written to.

Onxy runs a SMART scan when you launch it.

A SMART test encompasses a whole suite of tests, and what joemike said was that TechToolPro is the only utility of which he's aware that runs it and reports on each test individually, which gives you a much better idea of how your HDD is faring than does a simple aye or nay.

Artie is dead on. OnyX, Disk Utility, Cocktail, TinkerTool System, and a host of other utilities all use the same Unix command to perform a SMART check. It reports only an aggregate pass/fail. TechTool Pro actually talks to the drive itself and reports all of the several SMART parameters reported by the disk drive along with information on what the pass/fail value is for each SMART parameter.

TechTool Pro 8 shows 23 different SMART parameters reported by the HDD portion of the Fusion drive on my Mac mini and 10 SMART parameters for the SSD portion. The HGST drives in my RAID array report 19 SMART parameters but many are different parameters than are reported for either my other HDD or SSD. It all depends on what parameters the vendor collects and what pass fail limits the vendor sets for each.

The Google Labs test of HDD failures indicated SMART was a poor predictor of impending drive failure because the manufacturers set the SMART limits too high. SMART is better at telling the user the drive has already failed. Google Labs recommends the use of surface scans as the best predictor of impending drive failure. As I said previously it is the presence of NEW bad data blocks that is a reliable indicator the magnetic surface media on the drive is beginning to fail and flake off.

For my information, what does TTP report for the HDD portion of your fusion drive? I would like to see how it compares with mine.

• Raw read data rate
• thourghput performance
• Spin up time
• start/stop count
• reallocated sectors count *
• seek error rate
• seel tome performance
• power on hours
• Spin up retry count
• Drivepoercycle count
• unknown attributes**
• G-sense error rate
• Power on retract count
• Load/unload cycle count
• internal temperature
• Hardware ECC Recovered
• Reallocation Error Count *
• Current pending sector count
• uncorrectable sector count
• Ultra DMA CRC error count
• Load/unload retry count
• Free fall protection

* values I would put a lot of weight on.
** There are often parameters reported that are proprietary and otherwise unknown

Thanks, Joe. The questionable value in my readout is Temperature Changes. Internal Temperature appears to be perfect.

You didn't list Temperature Changes. Is that because you don't have it in the parameters or is it an omission?

Startup is really getting long.

If I buy Tech Tool, that's $100. If I find out the drive is failing, then I have to pay the addidtional cost of the drive. If I pay someone like Best Buy to install it, there's that cost. I looked into replacing the drive myself, on web sites and on YouTube, but it looks like a bear to do. I don't think I'm up for that. Lots of potential for disaster.

I wouldn't install a drive either. I saw a video about it at OWC and decided that that's something I wouldn't attempt. Of course, you don't know for certain that the drive is the issue. Still, TTP is not a bad investment. You'll be able to use it even if you get another computer.

Well, since you haven't got an appropriate utility, here's a Terminal command that will run a surface scan for you...


Copy and paste that into /Applications/Utilities/Terminal, hit return, enter your admin password at the prompt (it won't appear on-screen), and let 'er rip, but be prepared to wait, with how long depending on the specifics of your iMac.

If you don't understand your results, post them here and we'll help you out.

You can get some insight into the command and surface scans in general here.

SMART basically does two things. First, it tracks various parameters over the lifetime of the drive. Hours spun up, read failures, temperature extremes, head seeks, sector remaps, head recalibration, all sorts of things. There are a standard set of parameters, and every drive also adds some additional proprietary values to track as well. Second, each of those parameters can have a max or min allowable value. Temperature for example, usually has an upper limit, and if the drive ever experiences a temperature at/above that, that parameter is permanently marked as a failure. If <i>any</i> parameter has gone into failure mode, the entire SMART condition of the drive changes from PASS to FAILING. This is a one-way trip, there's no user-accessible way to change parameter values.

The problem I have with this is a lot of people seem to think that if SMART is passing, the drive's fine. But that's not what it means. It means the drive hasn't gotten bad enough to flag as failing yet. It may still have problems, some of which are clear indicators of impending doom for your data. I've done data recovery on <i>clearly failing<i> drives dozens of times, while SMART was passing the entire time. I've watched it change from PASS to FAIL during recovery numerous times. I've seen apps reporting disk IO errors while SMART remained in PASS condition. I've watched drives die on the table during recovery, with PASS being their dying breath. So I have very little respect for SMART, it's a bit of an oxymoron to its acronym.

The bottom line is that SMART can only do one thing, tell you when it's confident that the drive is dying or dead. It says <i>nothing</i> authoritative for the condition of the drive. If it says FAILING, you can be pretty certain it's failing. If it says PASS, you may as well ignore that, because it is of very little value, only saying "we're NOT absolutely sure the drive is bad". SMART is like asking your mechanic to look over your car and report its condition, and the mechanic tells you "Right now it appears to be running ok." <b>Not</b> very helpful. And certainly shouldn't inspire confidence in either the car <i>or</i> the mechanic. You want to know if it's about to kick the bucket, or is unsafe for a road trip, not whether the engine is currently on fire.

The only useful metric I've found is software that actively tests the performance of the drive. I think techtool has an option for that. My surface scan script and watchdrives script do exactly that. They've frequently identified failing drives that were passing SMART. They're also usable on drives connected on ports that don't support SMART polling, such as drives attached via firewire or USB.

So, V1, maybe you can answer my question above, in post #38437. Remember, this is the HDD portion of a fusion drive. The parameters have not changed since the drive was new (I looked a report from April, 2015).

I got this:

^C410165+0 records in
410165+0 records out
210004480 bytes transferred in 56.621826 secs (3708896 bytes/sec)
Macintosh:~ myname$ sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror
sudo: /var/db/sudo writable by non-owner (040707), should be mode 0700

Hmmm... I dunno what happened there.

^C terminated the process at about 210 MB...long before it ran its course. Did you do that yourself? (160 x 1,073,741,824 = 171,798,691,840...should be the final bytes transferred number for a 160 GB HDD.)

And the part I've highlighted in red is completely new to me.

But insofar as the scan ran it found no bad blocks.

Sorry, but this calls for an expert...not me.

I didn't stop it. I'm not sure it ran at all, or for very long. There was no indication that it was running.

You don't see any indication that it's running unless it hits a bad block (Edit:) or completes its run.

But "210004480 bytes transferred in 56.621826 secs (3708896 bytes/sec)" tells you that it ran for just under a minute before something aborted it.

Google turns up some results for "/var/db/sudo writable by non-owner (040707), should be mode 0700", but I'm not equipped to evaluate their usefulness.

At this point you need a UNIX guy to kick in.

Edit: I wonder why the command ran for a minute before spitting out an error...didn't do it immediately?

1. And if there are no spares, I assume that OS X spits out an I/O error?

2. A surface scan also discovers bad blocks that have never been written to, which underscores the wisdom of both running an immediate scan on a new drive as a benchmark for future scans and never zeroing all data (which maps out bad blocks) before running a discovery scan.

Edit: So in the sense of case 2, a "new bad block" would be one that has never been written to but has gone bad since it was last scanned.

You could try a permissions repair. SUDO is a juicy target for someone trying to hack the computer, as it's the mechanism by which processes elevate their privileges. So if it detects any abnormalities in any of the associated files, it will refuse to run. In this case it looks like it thinks the SUDO application itself is currently modifiable by anyone. Naturally it doesn't like that, so it's not going to run, because it may have been modified to allow someone access.

A surface scan

1. copies the data in the target blocks
2. writes a standard pattern(s) to that data block,
3. reads the block
4. compares what is read to what was written.
5. If they match it goes to step 7 .
6. Else the drive firmware will tray severe attempts to write and read before mapping the current block to a spare.
7. then it writes the original data to whatever block is mapped to that address

So if there was a previous scan, then every data block has been written to and any new bad blocks discovered will be NEW bad blocks.

Now do you see why a full surface scan is so time consuming?

btw mike that's referred to as a "destructive surface scan" because it writes. Many surface scans, including my script, are non-destructive and do not test write operations. This roughly cuts scan time in half. Some of the testing tools have a check box you can tick to turn on destructive write testing.

I was reading the logs in Console.

One message was "Can’t create kept cache under / - owner not root." I googled that and someone suggested typing in Terminal: "sudo chown root:admin /". So I did and got the response:

"WARNING: Improper use of the sudo command could lead to data loss or the deletion of important system files. Please double-check your
typing when using sudo. Type "man sudo" for more information. To proceed, enter your password, or type Ctrl-C to abort."

So I entered my password and got "sudo: /var/db/sudo writable by non-owner (040707), should be mode 0700"

Where there's a choice, I imagine the name would scare any but the most stout-hearted from using the option.

I've done a lot of things now, which obviously makes it tougher to know what worked.

I'm sure of one thing, that after I deleted my second account/guest account, restart and shutdown changed dramatically and are now instantaneous. Startup is somewhat faster, but still slow. I'm waiting to see if this is normal slow or abnormal slow.

Other things I did:

• Repaired permissions with Disk Utility and then Onyx.
• Terminal seems to work now. Console was giving me messages about "Failed to count the number of files in System/Library/StartupItems: no such file or directory." So I googled that problem and, based on advice, typed "cd /System/Library" and then "sudo mkdir StartupItems" and then my password.
• Disabled Login Items atext and Clip Menu.
• Deleted Logitech mouse software and replaced with demo of USB Overdrive.
• Re-installed FinderPop. I suspect this did nothing, though I may switch to an older version.
• Disconnected backup Firewire drive, which for many months I've left plugged in, turning it on only when I'm about to backup with SuperDuper.
• Disconnected DAC, which I've been using for about five days, turning it on only when I use it.

I should add that the slow restart and shutdown remained even after I disabled login items, deleted the Logitech software, and repaired permissions. Those obvious fixes weren't the solution. ETA: I suspect also that little was gained by unplugging the Firewire drive and the DAC.

Seeing as most people wouldn't expect a "test" to erase all their data, the scare is justified.

Yep, thanks.


Somehow it never registered on me that a scan actually wrote to a drive.

You ran into the same roadblock as you ran into with the scan command, i.e. it calls for sudo, and you've got a problem with your (quoting V1) sudo application.

I dunno... I guess your guest account somehow messed with sudo and deleting it cleared up the issue.

Just to play it completely safe I'll suggest that you now boot from your install disc or another volume and run Repair Disk from Disk Utility, and follow that with a rerun of the scan command (which should take about 80 800 minutes). (I guess it's best to let it run while you're out or sleeping; I'm not sure if you can work while it's running.)

I'm happy to hear that things are at least better.

There is a distinct advantage to the "destructive" surface scan. The scan has no way of knowing if the data stored in any given data block is what was originally written to that block other than by a parity check (and parity checking is a whole new subject). That means the data in that block may have changed or become corrupted due to the inability of the magnetic media to hold the data correctly. So a non-destructive surface scan can report a sector as good when actually it is failing or has failed.

I don't know the exact algorithm used by TTP and others for their "destructive" surface scans. It is a proprietary algorithm and from personal experience over the years has evolved greatly both in safety and in speed. I do know you can pull the power while TTP is performing a surface scan and no data will be lost, so while it is technically "destructive" it is a very tightly controlled destruction and reconstruction process.

For deniro's benefit, as far as I know you can run a surface scan while you're working.

Is that correct?

While that may be OK, not sure if I would do that. I have TechTool Pro, and whenever I run any of its' tasks (as part of my weekly disk cleanup/maintenance/repair processing, along with backing up via SuperDuper!), I just leave it alone. (I am actually performing such tasks on my two Macs at the same time). It has always been my belief (not sure if this has been stated anywhere else) that whenever one performs disk maintenance tasks and backups, nothing else should be running on the machine.

However, looking at TechTool forums about this, it is not explicitly stated that one cannot be using their machine while a Surface Scan is running. But, I still will only do it (plus the other TechTool tasks) while the machine is "quiet".

The surface scans for my Macs take less than 30 minutes, due to the size of the drive: 256 Gig SSD on my MacMini, and 250 gig SSD on my MacBool Air. I somewhat recently did a surface scan on one of my external, 7200 rpm, 1 TB dives, and I let it run overnight.

I'm going to launch it soon, and have TechTool do a surface scan on one of my external drives (my wife and I are going out). I'll let it run overnight.

OK, I just finished the Surface Scan of one of my external, 1 TB, 7200 rpm drives, and it is fine Took about 4 hours to complete. I am going to do the other one soon.

I suspect that because it spins at 7200 rpm, and that the connection to my Mac Mini is via Firewire 800, that helps to speed up the process.

As a point of information, is a surface scan relevant to a SSD? SSDs don't have moving parts to scan.

Here's MMT3's take on the subject.

Thanks!

Note that the information on that link is somewhat "old" (2013), but maybe still applicable. I have the latest version of TechTool Pro (V8.0.3), and I still use TechTool Pro to do a surface scan of my SSDs. I also use it to perform most of its other useful tasks. About the only thing that is not applicable to SSDs is Volume Optimization.

Here is a more recent "take" on this, along with some other features of TechTool Pro (all in relation to TechTool Pro V8.0.3):

http://www.micromat.com/forum-100002/search?q=Surface%20Scan%20with%20SSD&childforums=1

Given that the surface scanning tools I use, TechTool Pro 8, Drive Genius 4, and SoftRAID 5 all dismount the drive (or array) that is being scanned the answer would be NO. You might be able to work from another boot drive but the surface scan utilities typically use 100% of all four cores in my Mac mini as well as max out the disk I/O channel response time would be glacial.

Thanks.

I'm pretty sure that I've run scans with V1's "dd" command and worked at the same time with no perceptible effect, bad or otherwise...not even any slowdowns as I recall, but I'm also sure that your always sage advise is the wise way to go.

That is what I would also expect. And, even if one could, why jeopardize/interfere with the surface scan? One would naturally assume that the purpose of a surface scan is to find bad blocks, and such an investigation needs to be done under stable circumstances.

I installed TechTool Pro 6 for a brief experiment and found that even though my SSD and boot volume were unmounted during the few minutes I allowed it to run I was still able to multi-task with no noticeable system slowdown. (The scan used an average of about 25% of each of my deuced Mac(hina)'s 4 cores.)

I just ran it, V8.0.3, on my MacBook Air, and it took up more than 60% of its two cores. But, even if I tried to do something else (did not want to risk it), I would not want to write anything to the SSD while the scan is going on. That just seems counter productive to the purpose of the scan.

Also, one should be able to spare using their machine for some time. Scans of SSDs will be faster (25 minutes in my case, for a 256 gig SSD), and as I mentioned above, my 1 TB, 7200 rpm external f\drive, via a Firewire 800 connection, took 4 hours (also on the other 1 TB, 7200 rpm drive). Such scans can be done overnight.

I'm going to change that to I've got no idea whether anything was unmounted.

Taking a second look at your problem, the command you were trying in the second part is to fix a permissions problem, which itself has a permissions problem. So doing a permissions repair on that drive is really looking like a good idea right now. Did you try that?

Everything seems to be working fine since I deleted that second user account.

I just posed a lengthy question on Micromat about Surface Scans in general, and also specific to TechTool Pro 8.0.3. I suspect I'll have the answer soon, and I'll post it here.

As part of that, there are of course a number of factors to consider regarding the speed of the scan (I also mentioned all of these in the post):

1. SSD versus traditional hard drives.

2. Internal bus speeds.

3. External connectivity (USB 2.0, USB 3.0, Firewire 400, Firewire 800, and Thunderbolt)

4. Amount of free space on a volume.

For Repairing Permissions, instead of using either Disk Utility (as long as it is not the version with El Capitan), or using Terminal, you can download the excellent freeware program Onyx from here:

http://www.titanium.free.fr/onyx.html

Make sure you get the correct version for the OS you are using. That venerable product has been around a number of years, is rock solid, and has had numerous, positive reviews. I have been using it for so long, that I depend upon it (along with TechTool Pro and SuperDuper!). I typically need to run the Repair Permissions task at least twice for each of my Macs, even on a weekly basis. The software has some other useful tasks that should be used.

OK, here is what Micromat said:

"Thanks for your kind comments.

The Surface Scan reads raw data (blocks) from an entire device, from the first block to the last. It does not read files. Its operation is not affected by the partition map scheme or the types of volumes on the drive. The drive does not even have to have a partition map or any volumes on it. Think of a tone arm on a phonograph playing a record from the first groove to the runout groove, and you will have a useful, though not perfect analogy.

If other processes are making use of the drive or device for reading or writing while the Surface Scan is in progress, the scan will take more time, but it will in no way be less accurate. The operating system handles requests for reading and writing from devices, and puts them into a queue. The requests get executed in an orderly fashion.

The amount of free space has absolutely no effect on the time it takes to read every block on the device. The Surface Scan does not distinguish blocks that belong to files from blocks that do not. It just reads blocks, to make sure they can be read.

The faster the drive and the bus, the faster the scan will go. One would expect most of the reading to be sequential."

So, it looks like it is OK (and safe?) to be doing other tasks while a Surface Scan is going on. But, note that the Surface Scan will slow down some. And as others have pointed out, using other tasks will be somewhat slow also.

I suspected the amount of free space has nothing to do with a Surface Scan, and Micromat confirmed it.

And, as I suspected the speed of the Surface Scan depends upon the speed of the drive, the type of connectivity, the bus speed, etc.

Myself, I will still let Surface Scans run while nothing else is going on with either of my Macs.

I wondered if anyone could compare disk scan and repair on Tech Tool et. al. versus Speed Tools. The latter is only 29.95. I have an OEM version that I can upgrade.

http://www.speedtools.com/STU3.html

Well, it was last updated on 10-22-2013 with this comment:


And in addition to it's not being up to date, well...you can judge it's reviews for yourself.

I wouldn't touch it!

Edit: I just took a look at their website, and in addition to all else, you may be subject to an upgrade fee if they ever release an El Cap compatible version.

Edit 2: Oops! I just remembered that you're still running Snowy, but that doesn't change my opinion.

Micromat just had a special of $39.95 over the holidays for TechTool Pro. From what II remember, they always do that every year.

Also, sometimes TechTool Pro is part of those Mac "bundles" that appear from time to time. They are usually advertised on either www.macnn.com, or www.macupdate.com.

From what I have seen, the 3 top commercial, well reviewed, and solid Disk Maintenance/Utility programs are Disk Warrior, TechTool Pro, and Drive Genius. Onyx can also do some useful tasks, but no where as extensive as any of the 3 products I mentioned above.