basically system memory size vs block device size was the opposite way around of today... then again people could and did have many individual floppy disks.
I can imagine many programs doing this though.
Every time you reboot, it will repair the array.
edit: thinking about it, there's some good educational value, but maybe via vm than plopped on the interwebs :D
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...
> 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.
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.... =)
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.
- Put a bird^H^H ZFS on it
- Switch to RAID10 (a stripe of mirrors), and go 2/3 floppys wide so you can have some redundancy in each mirror gropu
- Get some Pis (or other SBCs) and hook those up and run Ceph... if this keeps going we'll have a SAN soon enough.
- ZIP disks?[0]
Also, I don't think I ever want to hear of the "hug of death" for any site ever again -- I don't think this site hosted on 30 floppies was hugged to death.
Though this may have been caused by me being in school and having to buy crappy white label ones. Couldn't afford those fancy imation ones with all the games I copied lol.
Thankfully, all entrance doors had an earplug dispenser...
Nothing is simple :D
Anyone want to try RAID0 on QIC tapes?
Also-
Tell me you're into Chiodos without telling me you're into Chiodos.
Big ol dose of nostalgia listening to your old metalcore tracks.
> Server uptime: 20 seconds
> Server load: 157.41 158.15 155.66
oh
P.S I am not going to and I am drunk.