You can safely ignore some errors that fsck reports....?

Question

I got the following report while Verifying in DU after installing the latest Security Update 2009-001. I took every possible precaution: installed in Safe Boot from standalone download, repaired Permissions before and after, disconnected all peripherals and stood on my head.
I repaired successfully, booted from the Disc. DU, while booted from the disc, saw the error too, so I know it wasn't a spurious error appearing only when booted from the HD. I'm wondering if there's anything here to be concerned about. I have never before had DU report the disc needed repair.
(I also repaired a Permissions error while booted in Safe Mode, before doing any of this. This was strange, since I'd just done a Permissions repair only a few days earlier for the QT Update. I won't get into that now, since I my main concern is the Disc error, and I don't want to overload this post with too many questions).
Checking volume bitmap.
Volume Bit Map needs minor repair
Checking volume information.
Invalid volume free block count
Invalid volume free block count
ead of %@)",2)
28212389
28211294
The volume Hard Drive needs to be repaired.
Error: The underlying task reported failure on exit
Both the Pogue, Missing Manual, Tiger, book and this KB article, report "Volume Bit Map needs minor repair" and "Invalid volume free block count " as "benign" errors, to be ignored.
"You can safely ignore some errors that fsck reports when journaling is enabled."
http://support.apple.com/kb/TS2028
I've been looking into this on my own, but here's the source of my confusion: 1. The heading of the KB article says it is for 10.3.9 or earlier (the article was last modified August, 2008), but way down at the bottom, 10.4 is listed under "Products Affected." Is this just someone at Apple being sloppy? 2. Both the Pogue Tiger book p.778, and the KB article describe this as an error that can be reported while repairing using fsck. They don't mention errors reported by DU, which is how I got this error. But just to be certain, can I safely assume it would apply to errors reported by DU as well? They are, effectively, the same thing, aren't they?
No strange sounds coming from the HD and everything seems to be fine. And no more reports of this kind coming from DU.

Answer 1

OK. Thanks very much,
My question arose because both the KB article and Pogue discuss these errors only in the context of running fsck. Since you say journaling is automatically turned off when DU does repairs, _does that, then, mean that these errors are only spurious when coming from fsck, not DU, because journaling is enabled in fsck? Journaling enabled is what causes them to appear in fsck?_ Is this why there's no mention of DU for these errors from the Apple KB article and Pogue? And does that mean that *if DU reports them, not fsck,* they are to be taken more seriously, that they are benign, meaning not very serious, but not to be dismissed completely as when they are reported by fsck?
Yes, the errors are benign, but should not be ignored.
I thought the KB article and Pogue were letting me off the hook completely. I see that's, maybe, not exactly the case.
*I never ran fsck.* I did everything from DU, either booted from the HD or the Tiger Installer disc. Fsck only came up because I discovered this KB article and the Pogue excerpt, which made me think that, since fsck is essentially DU, but run from a command line, they applied as well to the errors DU found. I didn't realize that, maybe, journaling enabled in fsck was at the heart of this issue.
As mentioned, I ran DU from the Tiger Installer disc and it repaired the error right away on the first run. I ran it twice just to be sure.
If DU ran successfully but did not repair the problem, then run Repair Disk repeatedly until no problems are reported.
There was no other problem, only the error DU reported, which was successfully repaired.
DU is supposed to disable journaling before repairing the drive. But there's nothing wrong with disabling journaling manually before repairing the drive.
Meaning I can't always assume it will? And, perhaps, it didn't this time and that's why I got the error?
Everything seems fine now; I was just somewhat alarmed, since I didn't understand where this could be coming from. I'd already verified the disc, booted from my clone, very recently.
Message was edited by: WZZZ