Hacker News Reader

Comment by game-of-throws | Hacker News Reader

You're playing with fire using RAID0. If I had data on 30 floppy drives, I'd want at least 20 of them to be parity drives.

View on HN

Seems like the bitrot is kicking in already. The main JPEG appears to have bitflip errors: http://totallynormalwebsite.ddns.net/megafloppy.jpg

This is what I get, when I download the full image and convert to PNG: https://i.imgur.com/JF4wtMg.png

During the conversion (with imagemagick), I get these errors:

  convert: Corrupt JPEG data: premature end of data segment `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
  convert: Corrupt JPEG data: found marker 0x74 instead of RST1 `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
  convert: Corrupt JPEG data: 206 extraneous bytes before marker 0xfb `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
  convert: Corrupt JPEG data: found marker 0xfb instead of RST2 `megafloppy.jpg' @ warning/jpeg.c/JPEGWarningHandler/403.
  convert: Unsupported marker type 0xfb `megafloppy.jpg' @ warning/jpeg.c/JPEGErrorHandler/345.

Looking closer, all bytes between offset 0x115C00 and 0x11F800 have been set to 0xf6, and all bytes from there until 0x11FC00 have been set to 0.

Bytes from 0x2EFC00 to 0x2F5C00 have been set to 0, followed by 0xf6's all the way until 0x2FFC00.

I'd be curious to know what failure mode(s) conjured the 0xf6's into existence.

Edit: Original version is here https://web.archive.org/web/20220715175852if_/http://totally...

heh, that's even worse than when I saw it:

https://i.imgur.com/Z2HwkwY.jpeg

I managed to grab a (hopefully) uncorrupted version somehow. I'm putting it somewhere other than imgur so they don't recompress the image. MD5 d30fcc384a8e2de4fab3056bde42b00b. [EDIT: Removed dead link, use archive.org instead]

> I'd be curious to know what failure mode(s) conjured the 0xf6's into existence.

Today's fun fact: The MS-DOS `format` command fills the disk with 0xf6, not 0x00. Though this is linux running on Mac hardware, reading a disk that should have actual data, so maybe that isn't the reason.

Perhaps the read head seeked (sought?) to the wrong offset, causing empty blocks to be read.

The link you gave is deleted.

Thanks, edited. I guess they didn't like all the traffic. Luckily archive.org has a copy too.

> Today's fun fact: The MS-DOS `format` command fills the disk with 0xf6, not 0x00.

Another fun fact: That character is ö under Windows-1252, the codepage in use by Windows since about Windows 2.0, and some late MS-DOS.

Wow that explains the öööööööö I remember seeing back in the day when I first ever downloaded a hex editor and opened a drive I had raw.

Funny co-incidence, in the Finnish language when you don't know what to say, you can say "Ööh". Data not found.

hmm... is it possible to correct those errors? I have some old images with errors, and I've always wondered if it were possible to fix the individual corrupted bytes to restore at least the remainder of the photos.

Yes it's possible, the SpaceX subreddit community did that to recover imagery from one of the early rocket landings which was corrupted due to poor antenna alignment between the transmitter on the landing barge and the remote receiver.

Just quickly remove some drives and set the write protect slider on them, problem solved, no data loss

Oh that write protect could prevent wear and tear!

A few years ago I finally bought a USB drive to read an old 3.5" floppy from the late '90s on which I had archived my e-mail messages before moving away to college. I completely forgot about write protection (as well as atime write-backs). I managed to read a surprising amount of data off of the disk, but I think less than if I had remembered to write-protect the disk before inserting it into the drive. The files were in mbox format, probably from Eudora, but possibly Pine. As is my habit, I first poked around with ls and less before copying the files over, and I'm pretty sure I ended up with more corruption than what I first saw with less.

Oh well. The irony is that to this day I have a tick of idly running `sync` at the command prompt, which I developed dealing with floppy and hard disk corruption running early versions of Linux. A crash or (IIRC) even a simple reboot sometimes resulted in disk corruption preventing Linux from booting. Reinstalling Slackware from floppy disks took quite awhile on its own, especially if installing the X11 disk sets, but half the time at least one of the disks would be corrupted, requiring me to download a fresh copy (using Windows--I was dual booting) over my 2400 baud modem, and then restarting the install from scratch. I probably went through this procedure at least a half dozen times, or at least enough to develop the tick. It was the best of times, it was the worst of times.... =)

So rare to see ppl writing about sync.

sync;sync;halt was once a legit way to shut down ;)

Or maybe three times sync;sync;sync just to make sure :)

I know of a company whose sysadmins still put sync;sync;sync in the scripts they deploy on customers’ machines… just because “you never know”.

Don't forget to park the hard drive heads!

There was a time when the sync CLI exited before the work was done, so you actually didn't want sync;sync;halt, typing it as separate commands gave it the right amount of time to complete.

that's the point, RAID0 is for speed only

> RAID0 is for speed only

In this case, the theoretical maximum bandwidth is 24MBit/s.

The problem is the old, slow usb bottleneck. I'm not sure how much faster, probably hundreds of bps rather than under 24, but a faster RAID0 rig would be to instead have 30x Mac G4 Digital Audios connected via gigabit switch, and share then RAID0 the internal floppies. It would also have whatever advantage running an XGrid PPC cluster on Tiger might provide. These boxes also ran PPC Ubuntu; no doubt Linux would eek out a dozen or so more bps, plus beowulf.

I don't know about that BW claim. Back when mp3 was new and computers usually had floppy drives I did the obvious and mp3 bitrates above 64K or so tended to stutter and significantly below 64K did not stutter.

Something like voice encoded at 32K sounded at least as good as a phone and played back off a 1.44 floppy and IIRC that was about the best that could be done.

You will probably be surprised how long an audio recording can be, if its voice at a low rate on one floppy. If you go variable bit rate and silence detection I subjectively remember "ten minutes" was quite reasonable on a 1.44 disk.

Extrapolating from historical experience, thirty or so in parallel should push over half a meg/sec quite reliably.

If you record speech onto a floppy drive off a cheap mic you'll record the sound of the floppy in the recording, which is funny to me.

I wish I still had those files. Useless, of course, but would be funny.

You also have faster and slower floppy drives. This video by Cathode Ray Dude explores some https://www.youtube.com/watch?v=wWwp3vVtElw

He got results ranging from 25 KB/s - 100 KB/s

Reply on news.ycombinator.com