4 ms·

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.

muhammadusman 4y ago
that's the point, RAID0 is for speed only
- Maursault 4y ago
  > 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.
  - VLM 4y ago
    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.
    - kalleboo 4y ago
      You also have faster and slower floppy drives. This video by Cathode Ray Dude explores some https://www.youtube.com/watch?v=wWwp3vVtElw https://www.youtube.com/watch?v=wWwp3vVtElw He got results ranging from 25 KB/s - 100 KB/s
_joel 4y ago
Just quickly remove some drives and set the write protect slider on them, problem solved, no data loss
- drewzero1 4y ago
  Oh that write protect could prevent wear and tear!
- wahern 4y ago
  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.... =)
  - kjellsbells 4y ago
    So rare to see ppl writing about sync. sync;sync;halt was once a legit way to shut down ;)
    - aldrich 4y ago
      Or maybe three times sync;sync;sync just to make sure :)
Retr0id 4y ago
Seems like the bitrot is kicking in already. The main JPEG appears to have bitflip errors: http://totallynormalwebsite.ddns.net/megafloppy.jpg 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 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://totallynormalwebsite.ddns.net/megafloppy.jpg https://web.archive.org/web/20220715175852if_/http://totally...
- kop316 4y ago
  heh, that's even worse than when I saw it: https://i.imgur.com/Z2HwkwY.jpeg https://i.imgur.com/Z2HwkwY.jpeg
- game-of-throws 4y ago
  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.
  - Retr0id 4y ago

muhammadusman 4y ago

that's the point, RAID0 is for speed only

Maursault 4y ago
> 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.
- VLM 4y ago
  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.
  - kalleboo 4y ago
    You also have faster and slower floppy drives. This video by Cathode Ray Dude explores some https://www.youtube.com/watch?v=wWwp3vVtElw https://www.youtube.com/watch?v=wWwp3vVtElw He got results ranging from 25 KB/s - 100 KB/s

_joel 4y ago

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

drewzero1 4y ago
Oh that write protect could prevent wear and tear!
wahern 4y ago
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.... =)
- kjellsbells 4y ago
  So rare to see ppl writing about sync. sync;sync;halt was once a legit way to shut down ;)
  - aldrich 4y ago
    Or maybe three times sync;sync;sync just to make sure :)

Retr0id 4y ago

Seems like the bitrot is kicking in already. The main JPEG appears to have bitflip errors: http://totallynormalwebsite.ddns.net/megafloppy.jpg 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 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://totallynormalwebsite.ddns.net/megafloppy.jpg https://web.archive.org/web/20220715175852if_/http://totally...

kop316 4y ago
heh, that's even worse than when I saw it: https://i.imgur.com/Z2HwkwY.jpeg https://i.imgur.com/Z2HwkwY.jpeg
game-of-throws 4y ago
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.
- Retr0id 4y ago