A/UX damaged partition

[Dennis Nedry]

I believe that the partition on my A/UX system is damaged because every time I boot it up, it comes up with all sorts of disk errors. It asks me to fix them, which I say enter "Y" a million times (lots of errors), and eventually it fixes it and reboots. It then boots to a terminal instead of the Finder. If I shut down and restart, all the errors come back.

I have a good install of A/UX 3.0.1 on an external HD, and when I boot form that on the Mac, the Mac partition of the internal HD mounts, but not the A/UX partition.

I can only assume the A/UX partition is damaged. If I can repair the partition, I think it would be fun messing around and copying files form the external HD into the internal to figure out specifically is wrong, why it won't boot to the Finder. Just for fun. I could just wipe the drive and reinstall everything, fixing all these problems easily, but where's the fun in that if I don't know what actually went wrong?

So I found a 68k version of Norton Utilities (v3.2), and I ran Disk Doctor on the internal HD. But Norton can't do anything to an A/UX partition. What can I do to fix the A/UX partition without reformatting? I am able to boot A/UX from the external HD and run A/UX stuff with the internal, damaged HD present if that helps at all.

 

[porter]

I have found certain SCSI disks don't work well with the power-down on A/UX.

My theory is a write has been written to the disk but is still within the disk's on board card waiting to be written and the power is removed you then end up with a corrupt disk.

The two solutions I have are

(a) instead of shutting down in A/UX do a reboot, then shutdown from Mac OS when that starts (eg abort the A/UX boot application)

( B) change to a SCSI drive that does not have this behaviour.

For my uses I am happy with small A/UX drives and keep my data on NFS volumes so am not worried in A/UX does corrupt itself.

 

[Udo.Keller]

I have found certain SCSI disks don't work well with the power-down on A/UX.
My theory is a write has been written to the disk but is still within the disk's on board card waiting to be written and the power is removed you then end up with a corrupt disk.

The two solutions I have are

(a) instead of shutting down in A/UX do a reboot, then shutdown from Mac OS when that starts (eg abort the A/UX boot application)

( B) change to a SCSI drive that does not have this behaviour.

Just my two cents: Disabling the write cache of the disk solved all the problems here.

 

[ChristTrekker]

Just my two cents: Disabling the write cache of the disk solved all the problems here.

Were your issues exactly the same as described? If so, I will add it and your suggestion to the FAQ.

 

[Udo.Keller]

Just my two cents: Disabling the write cache of the disk solved all the problems here.

Were your issues exactly the same as described? If so, I will add it and your suggestion to the FAQ.

The issues were the same or even worse. One time I've lost a complete file system.

Two observations:

(1) Consider a hard disk with A/UX volumes that works well in a SE/30. The same disk, mounted in a Quadra 650, suddenly begins to have problems with corrupted file systems. The Quadra 650 does auto power off, the SE/30 cannot. Instead, the SE/30 typically ends the shutdown sequence with a message like "It is now save to power off your Macintosh".

(2) I had a look on two different Apple-labeled disks. Both of them had the write cache disabled, whereas their non-Apple equivalents have the write cache enabled. Two disks is certainly not enough to feel statistically safe, and I have no information about the original Apple specific drive parameters, but to me it looks like Apple disabled the write cache intentionally.

Further investigation would certainly be helpful, because disabling the hard disk write cache means degrading the I/O performance, and I/O is not the strongest discipline anyway. But for the time being it might be a useful workaround.

 

[Charlieman]

Performance from the HD SC Setup 3.01 formatter seems very modest according to these benchmarks:

http://www.euronet.nl/users/ernstoud/bnchmrks.html

Sustained write is slower than any third party formatter, and sustained read is scarily bad. To me, the numbers imply that write cache is off.