Apple file management WTF?



  • I saw this comment  a while ago on Slashdot and it sounds like the scariest WTF I've ever heard.  There's some questioning what actually caused it, but no one seems skeptical that it actually happened.  Can anyone here confirm or disprove it?



  • Almost nobody in that thread seems to believe that it actually happened as described.

    The exceptions are from people posting comments like this (with a definite daFei flavour):

    "This has been a serious flaw in Unixes since I knew about it.
    The OS will let your HD fill up and overwrite itself."

    Actually, the error report itself is so vague and confused that I wonder if the guy has any clue what he is talking about. He claims that a userspace program, through MacOSX, managed to corrupt a track on the hard drive so badly that the drive itself refused to start afterwards. This sounds patently unbelievable - it's seems far more probable that he kept powercycling the computer rapidly until something interesting happened.

     



  • Sounds as if someone didn't know how to run fsck, really. System crash in the middle of writing a large file causes disk corruption - not nearly as common as it used to be, but sure it could still cause weirdness like an undeleteable file if the drivers aren't perfect, though you'd expect it to be fsck'able. If it was caused by real physical disk damage - the old quads were prone to high heat, the new ones less so - there's a good chance it'd fail this way, and he says his disk was replaced, not reformatted and reinstalled. But the claims of overwriting track 0 are just wild speculation, since it was never attached to another system and scanned with a low-level disk viewer.



  • I don't think [i]any[/i] operating system would allow that sort of behavior. No user application has that sort of access to writing to the disk like that.



  • [quote user="djork"]I don't think [i]any[/i] operating system would allow that sort of behavior. No user application has that sort of access to writing to the disk like that.[/quote]

    Certainly Mac OS X doesn't. Even the worst possible flaw in the OS wouldn't cause the disk to be unusable. You might need to reformat the disk if an OS error caused the filesystem to be corrupted, but that's about it. The guy had a hardware failure, and blamed it on the OS. This sort of confusion is pretty common among unsophisticated users.



  • [quote user="djork"]I don't think [i]any[/i] operating system would allow that sort of behavior. No user application has that sort of access to writing to the disk like that.[/quote]

    I was writing a program for my Pocket PC a year or two ago to copy big (300MB+) files from my USB hard drive to the internal SD card - I accedently tried to copy a 350MB file into the 128MB of internal RAM, and after filling up the internal RAM the PPC crashed and wouldn't reset (as in - I hit the reset button, and the screen goes white and stays there for hours).  I did a hard reset, and that wiped the internal file store and now it works fine.  But I added a line of code to make sure you couldn't copy files to the internal RAM.  

     It was a Toshiba e800 (wonderful PPC BTW) running Windows Mobile 2003SE, and I nuked it by filling up the internal memory 100%.

     



  • I don't know much about hard drives, but isn't it impossible to destroy any decently modern one through software?  Can the OS even see the low level stuff like track 0?  If it overwrites other files however, that's still a pretty big WTF.



  • [quote user="Cap'n Steve"]I saw this comment  a while ago on Slashdot and it sounds like the scariest WTF I've ever heard.  There's some questioning what actually caused it, but no one seems skeptical that it actually happened.  Can anyone here confirm or disprove it?[/quote]


    There's no way to absolutely disprove it, of course, since there may have been some bizarre thing going on that allowed it to happen which won't show up anywhere else, but I've had QuickTime Player on OS X fill up the hard disk completely during export, and it just brings up an error message and erases the export file, leaving the space free again. I've even had it happen in a FileVault account, which meant that the space "freed up" was not immediately available to the system, and it still didn't bring down the system or make it impossible to reboot.

    That suggests that, if this problem really is what the user claims, it's something unique to the G5s, or maybe to the quad-processor models. Maybe some kind of horrible race condition that only activates, in Mac OS X, on a machine with two dual-core chips -- sequence being something like: thread 1 on processor 1 checks free space, finds > 0, thread 2 on processor 2 checks free space, finds > 0, thread 1 writes, thread 2 writes? That seems plausible to me, since the guy is using the first model Apple ever made which uses multi-core CPUs AND multiple CPUs at the same time.



  • [quote user="The Vicar"]

    That suggests that, if this problem really is what the user claims, it's something unique to the G5s, or maybe to the quad-processor models. Maybe some kind of horrible race condition that only activates, in Mac OS X, on a machine with two dual-core chips -- sequence being something like: thread 1 on processor 1 checks free space, finds > 0, thread 2 on processor 2 checks free space, finds > 0, thread 1 writes, thread 2 writes? That seems plausible to me, since the guy is using the first model Apple ever made which uses multi-core CPUs AND multiple CPUs at the same time.
    [/quote]

    Doubtful.  Programming-wise, there's no difference between a quad-CPU system and a dual-core dual-CPU system.  The dual-dual will run a little bit slower due to bus contention, or a lot slower if the dual cores share a cache, but the code can't tell the difference.



  • [quote user="Cap'n Steve"]I don't know much about hard drives, but isn't it impossible to destroy any decently modern one through software?  Can the OS even see the low level stuff like track 0?  If it overwrites other files however, that's still a pretty big WTF.[/quote]

    There is nothing special about track 0.  Actually the whole concept of tracks on hard drives is obsolete to the OS since the IDE standard can only access about 500MB useing track, head, sector notation.  You need to use raw block numbers after that.

     Overwritting the whole disk cannot damage it.  In fact 'dd if=/dev/zero of=/dev/hdd_device_name' is a good way to erase a drive in Unix like OSs. 

    What is important about the start of the disk is that the OS stores important information there, like the partition table and boot code.  Erasing this information would make the disk unreadable by the OS, but could easily be rewritten using the normal disk setup utilities, erasing all the data in the process.  DIsk repairt programs may still be able to recover files first.

    The real WTF is that the OS let a user space program overwrite critical data.
     



  • [quote user="Carnildo"][quote user="The Vicar"]

    That suggests that, if this problem really is what the user claims, it's something unique to the G5s, or maybe to the quad-processor models. Maybe some kind of horrible race condition that only activates, in Mac OS X, on a machine with two dual-core chips -- sequence being something like: thread 1 on processor 1 checks free space, finds > 0, thread 2 on processor 2 checks free space, finds > 0, thread 1 writes, thread 2 writes? That seems plausible to me, since the guy is using the first model Apple ever made which uses multi-core CPUs AND multiple CPUs at the same time.
    [/quote]

    Doubtful.  Programming-wise, there's no difference between a quad-CPU system and a dual-core dual-CPU system.  The dual-dual will run a little bit slower due to bus contention, or a lot slower if the dual cores share a cache, but the code can't tell the difference.
    [/quote]

    Dunno... the Mach kernel is a darned weird thing, and Mac OS X uses it in a way which is unusual compared with the way other Mach-based projects do it nowadays. (The BSD subsystem is not completely abstracted from Mach in Mac OS X, so if one dies they other does too, the usual justification being that if the BSD subsystem goes down the system is hosed anyway so there's no point in keeping Mach up.) It would not surprise me -- and keep in mind, I like Macs -- if there was some weird problem that crops up in Mac OS X when you combine writing a large file with multiple multi-core CPUs.

    On the other hand, of course, you may be quite right. It just seems more likely, in light of my machine NOT having this problem, that it's something related to the specific combination of hardware.



  • [quote user="ShawnD"]

    [quote user="Cap'n Steve"]I don't know much about hard drives, but isn't it impossible to destroy any decently modern one through software?  Can the OS even see the low level stuff like track 0?  If it overwrites other files however, that's still a pretty big WTF.[/quote]

    There is nothing special about track 0.  Actually the whole concept of tracks on hard drives is obsolete to the OS since the IDE standard can only access about 500MB useing track, head, sector notation.  You need to use raw block numbers after that.

    [/quote]

    In IDE drives, hardware track 0 (which is not the same as logical track 0) is where drive calibration information is stored, the idea being that the drive electronics can find that track on powerup without calibration, and then use that information to compensate for how the particular drive differs from the theoretical layout.  If hardware track 0 gets overwritten (which shouldn't be possible, as the rest of the computer doesn't have access to it) the drive is hosed.



  • [quote user="Carnildo"][quote user="ShawnD"]

    [quote user="Cap'n Steve"]I don't know much about hard drives, but isn't it impossible to destroy any decently modern one through software?  Can the OS even see the low level stuff like track 0?  If it overwrites other files however, that's still a pretty big WTF.[/quote]

    There is nothing special about track 0.  Actually the whole concept of tracks on hard drives is obsolete to the OS since the IDE standard can only access about 500MB useing track, head, sector notation.  You need to use raw block numbers after that.

    [/quote]

    In IDE drives, hardware track 0 (which is not the same as logical track 0) is where drive calibration information is stored, the idea being that the drive electronics can find that track on powerup without calibration, and then use that information to compensate for how the particular drive differs from the theoretical layout.  If hardware track 0 gets overwritten (which shouldn't be possible, as the rest of the computer doesn't have access to it) the drive is hosed.

    [/quote]

    I was pretty sure this is stored in ROM, or at least read-only flash memory, for many years now. 



  • [quote user="foxyshadis"][quote user="Carnildo"][quote user="ShawnD"]

    [quote user="Cap'n Steve"]I don't know much about hard drives, but isn't it impossible to destroy any decently modern one through software?  Can the OS even see the low level stuff like track 0?  If it overwrites other files however, that's still a pretty big WTF.[/quote]

    There is nothing special about track 0.  Actually the whole concept of tracks on hard drives is obsolete to the OS since the IDE standard can only access about 500MB useing track, head, sector notation.  You need to use raw block numbers after that.

    [/quote]

    In IDE drives, hardware track 0 (which is not the same as logical track 0) is where drive calibration information is stored, the idea being that the drive electronics can find that track on powerup without calibration, and then use that information to compensate for how the particular drive differs from the theoretical layout.  If hardware track 0 gets overwritten (which shouldn't be possible, as the rest of the computer doesn't have access to it) the drive is hosed.

    [/quote]

    I was pretty sure this is stored in ROM, or at least read-only flash memory, for many years now. 

    [/quote]

     I also thought that too... Factory set stuff in a ROM and things like bad sector map and SMART logs in flash or similar.


Log in to reply