Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

File system journaling won't prevent all disk damage System
Today I discovered that just because one has file system Journaling enabled, that doesn't mean one still shouldn't check such HDs from time to time with a disk repair utility, or that a Journaled HD cannot get directory damage from means not protected by Journaling (such as an app run amuck or a power surge or cosmic rays corrupting RAM).

I had a disk that barely mounted, making horrible grinding "seek" noises. So I ran Apple Disk Utility's Disk First Aid and it reported that its second partition had "minor volume bitmap damage." This was *not* the spurious report of damage associated with Journaling (the first partition reported no errors) as reported in Apple's fsck Reports Benign Errors When Journaling Is Turned On.

But Disk Utility refused to affect a repair because journaling was enabled. So I disabled journaling in Cocktail, then went back and ran the repair. Success! All is well now.

Then I turned journaling back on, and I'll still always use it, for it's safer than not doing so, but a word to the wise.
    •    
  • Currently 2.60 / 5
  You rated: 3 / 5 (5 votes cast)
 
[11,906 views]  

File system journaling won't prevent all disk damage | 16 comments | Create New Account
Click here to return to the 'File system journaling won't prevent all disk damage' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
File system journaling won't prevent all disk damage
Authored by: aranor on Jan 16, '04 12:08:09PM

Why did you use Cocktail? You can turn Journaling on and off through Disk Utility. Either edit the toolbar or look in the File menu.



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: gmachen on Jan 16, '04 01:32:24PM

>Why did you use Cocktail? You can turn Journaling on and off through
>Disk Utility. Either edit the toolbar or look in the File menu.

Not in Jaguar.



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: droemel on Jan 16, '04 12:38:53PM

You can also use "AppleJack" (->versiontracker) for using maintenance in single user mode. It also works with journaled drives.



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: TimBonnici on Jan 16, '04 01:00:21PM

To check a journalled startup disk you can also restart in single user mode (hold down Cmd-S at startup) and then type fsck -y. Fsck refuses to run at first, pointing out that the drive is journalled, but tells you whatever flag is necessary to force a check on a journalled disk. (I think it is -f)



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: gmachen on Jan 16, '04 01:51:31PM

> To check a journalled startup disk you can also restart in single
> user mode (hold down Cmd-S at startup) and then type fsck -y

This command only will work for the startup volume (which mine wasn't).
While there is an arcane variant that works on non-startup volumes, who but students
of Unix with upmteen years under their belts will remember the procedure while in single-user mode?

If you think a GUI is for wimps, there's always Linux.



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: dthorburn on Jan 16, '04 09:06:16PM
>To check a journalled startup disk you can also restart in single user mode (hold down Cmd-S at startup) and then type fsck -y

This command only will work for the startup volume (which mine wasn't).

By default, fsck will look at all volumes mentioned in the system's files system table (/etc/fstab according to the manual). You can also specify exactily which file system you want to check from the command line.

While there is an arcane variant that works on non-startup volumes, who but students of Unix with upmteen years under their belts will remember the procedure while in single-user mode?

Well, I have 10 years experience with Unix and I still can't remember all the options to all of the programs I use - especially fsck[*]. However I do know how to read a the online manual and find out.

Fortunately single-user mode still allows you to read the online manual.

If you think a GUI is for wimps, there's always Linux.

I'm sorry, I missed your point there .....

Douglas

[*] fsck is one of those programs that you don't want to have to run manually ;-)



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: gmachen on Jan 17, '04 12:17:07AM

No! To repeat, ...

/sbin/fsck -y
or
/sbin/fsck -f

... only will address the startup drive.

To do an fsck on other drives, see the following arcane tutorial:

"How To Run fsck To Examine A Non-boot Volume In Mac OS X"

http://www.osxfaq.com/Tutorials/fsck/



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: imageworx on Jan 19, '04 11:22:57AM

sbin/fsck -fy will repair a journaled startup volume

You can mount and repair other volumes but need to know the device name.

Personally, I turned journaling off as it does affect the performance. And I would not have journaling on anything but the startup volume (if you must).

OT: I have a Deskstar (aka deathstar) that once in awhile will make a noise. (rrrt rrrt rttt.....rrt rrrtt rrttt....rrrrt rrrtt rrrttt....) then go away. What is that? I'll get that when repairing permissions...or even when I ran Disk Warrior (latest). But nothing is found wrong. Should I replace the drive? SMART indicates the hardware is fine.


---
To BeOS or Not to BeOS



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: gmachen on Jan 19, '04 12:12:36PM

After twenty years, I see that TheWormyFruit™ finally wised-up and its new Xserve G5
switched to ECC memory! It's about damn time! (Now if only we lowly consumers could
gain some protection against cosmic rays!)



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: brontitall on Jan 16, '04 04:44:55PM
[a journalled filesystem is vulnerable to] damage from means not protected by Journaling (such as an app run amuck or a power surge or cosmic rays corrupting RAM)
I'm sorry, but as an enterprise unix user for over 10 years I can't accept this. I've many times run machines for literally years with no filesystem corruption.
  • An "app run amuck" should never have direct access to the disk, that's reserved for the kernel.
  • The whole point of journalling is that the disk is always left either in a self-consistent state, or in a state that is quickly returned to a self consistent state.
If filesystem corruption is happening, the only options are:
  • Faulty hardware (I include hardware that is overly sensitive to "cosmic rays"
  • Bugs in the kernel filesystem code path (filesystem, disk drivers, etc). I would like to think this is not the case, since that code-path is one of the most crucial in the OS. If you can't trust saving files to disk, you may as well use a pen and paper.


[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: gmachen on Jan 16, '04 06:04:42PM

> I'm sorry, but as an enterprise unix user for over 10 years I can't accept this.

I bow to your Indubitable Incontrovertible Authority. ... Oh, wait a minute; it really happened, more than once!


> I've many times run machines for literally years with no filesystem corruption.

Don't doubt it for a minute. Doesn't change my point.


> An "app run amuck" should never have direct access to the disk, that's reserved for the kernel.

Doesn't stop apps corrupting my prefs files all-too-often, the kernel duly passing along the
run-amuk data. But I agree that the disk directory *ought* to be out of the hands of an unruly
app. Nevertheless, my disk directory still gets corrupted from time to time, notwithstanding Journalng.


> The whole point of journalling is that the disk is always left either in a self-consistent
> state, or in a state that is quickly returned to a self consistent state.

Yet even the Journaling man pages admit that files can disappear in the process. A consistent
state is no substitute for a good backup!


> If filesystem corruption is happening, the only options are:
> Faulty hardware (I include hardware that is overly sensitive to "cosmic rays"

Sounds like you're pooh-poohing the fact that cosmic rays are well-known to corrupt RAM
that *isn't* faulty (albeit infrequently); and that reason precisely is why Apple separately has
to supply *parity* RAM to Macs sold to government & military installations, to comply with
their purchase criteria.


> Bugs in the kernel filesystem code path (filesystem, disk drivers, etc). I would like to think this is
> not the case, since that code-path is one of the most crucial in the OS. If you can't trust saving files
> to disk, you may as well use a pen and paper.

To repeat, I sometimes get disk directory corruption despite Journaling. For example, just last night
I ran a Verify of my backup to another hard disk with Synchronize Pro X and its log reveals:

* The files named "ClipWorks 2.0.1.sit alias" differ at offset 2559 (09FF hex) in the RESOURCE fork.
* The files named "Proxy Bouncer 3.0-SOCKS4.sit " differ at offset 259 (0103 hex) in the RESOURCE fork.
* The files named "APM Tuner 1.0b1 ƒ alias" differ at offset 291 (0123 hex) in the RESOURCE fork.
* The files named "hfspax 1.0fc4-backup.tar.gz" differ at offset 51164 (C7DC hex) in the RESOURCE fork.
* The files named "Partition Fixer™ v1.1" differ at offset 2591 (0A1F hex) in the RESOURCE fork.
* An error occurred while getting the location of a file being written. File system I/O error.

I don't care whether it's a bad FireWire cable, RF interference, power surge, or whatever - in lieu of
pen & paper, I'll continue to run my diagnostic utilities and religiously keep frequent backups.

I stand by my assertions.



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: stetner on Jan 16, '04 06:44:02PM

If I was getting 5 or six errors on a backup, I would be tearing my system apart looking for bad hardware.

Either that or you are in a very intense cosmic ray area and should run for your life! 8-0



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: gmachen on Jan 16, '04 08:15:49PM

> If I was getting 5 or six errors on a backup, I would be tearing my system apart looking for bad hardware.

I apologize: In my haste I failed to mention - which changes the meaning completely - that ...

1) A backup/verify went fine.
2) Later - following at least one restart - I discovered disk directory damage, notwithstanding Journaling, in Disk Utility's Disk First Aid.
3) Disabled Journaling, successfully repaired directory damage in Disk First Aid, re-enabled Journaling.
4) Ran the backup program's verify and observed the failures.


> Either that or you are in a very intense cosmic ray area and should run for your life! 8-0

McKee, W. R., McAdams, H. P., Smith, E. B., et al.
"Cosmic Ray Neutron Induced Upsets as a Major Contributor to the Soft Error Rate of Current and Future Generation DRAMs"
1996 IEEE Annual International Reliability Physics, pp. 1-6, 1996.

Tosaka, Y., Satoh, S., et al.
"Cosmic Ray Neutron-Induced Soft Errors in Sub-Half Micron CMOS Circuits"
IEEE Electron Device Letters, V. 18, N. 3, pp. 99-101, March 1997.

Ziegler, J. F., Nelson, M. E., Shell, J. D., et al.
"Cosmic Ray Soft Error Rates of 16-Mb DRAM Memory Chips"
IEEE Journal of Solid-State Circuits, V. 33, N. 2, pp. 246-252, February 1998.



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: brontitall on Jan 17, '04 07:59:10PM

Don't get me wrong, I'm not doubting that you have file system corruption, I'm just peeved at what I see is an attitude among many Mac users at just accepting that such things are a fact of life and working around it. This may not apply to you, but certainly does to many others. Maybe it's what they've been used to in Classic MacOS, but in this day and age it's not good enough.

What I was getting at was that if this IS the result of bugs in the code the we should all be screaming blue murder at apple to fix one of the most crucial parts of the kernel. If it's hardware issues with third party hardware then there's not much they can do about it.

As for cosmic rays, don't get me started on lack of parity/ECC RAM. I've had unreported file corruption due to one bit in 1GB of RAM in my laptop being stuck. The worrying thing is that the Apple Hardware test CD reported no faults, but a little user-space app that I coded up in an hour could see the problem!



[ Reply to This | # ]
File system journaling won't prevent all disk damage
Authored by: johnsawyercjs on Jan 31, '05 11:49:52PM

* The files named "ClipWorks 2.0.1.sit alias" differ at offset 2559 (09FF hex) in the RESOURCE fork.

...

* An error occurred while getting the location of a file being written. File system I/O error.

The errors gmachen cites in the message above, referring to resource fork errors, are references to file damage, not directory damage, except the last error, which may refer to directory damage--it's too generally worded to tell. Though directory damage can cause file damage, I'd be careful about interpreting file damage as directory damage--files can get damaged even if a volume's directory remains pristine.



[ Reply to This | # ]
Now THAT'S a thread!
Authored by: jiclark on Jan 17, '04 12:46:47AM

;-}



[ Reply to This | # ]