51–60 of 161 posts
Imagine a floppy disk based old server surviving “Hug of deaths” while the latest react based static website hosted on Kubernetes for infinite scalability on baremetal dies in like 5 sec.
Imagine indeed. This has been suffocated already it seems. Images can't even finish loading.
Earlier quoted context omitted.
No. The cache is at the block layer, not the file/directory layer. So the filesystem will look up the directory structure, which will be cached.
On top of the block layer cache there's also the namei cache for filename to inode lookups, I'm not sure if that covers a file not found case or just a success path, but it may apply here too.
Earlier quoted context omitted.
No. The cache is at the block layer, not the file/directory layer. So the filesystem will look up the directory structure, which will be cached.
On top of the block layer cache there's also the namei cache for filename to inode lookups, I'm not sure if that covers a file not found case or just a success path, but it may apply here too.
Earlier quoted context omitted.
that's the point, RAID0 is for speed only
> RAID0 is for speed only In this case, the theoretical maximum bandwidth is 24M Bit /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 cl…
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'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.
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/4…
Earlier quoted context omitted.
I'm used to referring to lots of IO as "noisy" or "chatty", but then I imagine sitting next to 30 floppy drives and that brings it to another level.
https://www.youtube.com/watch?v=kCCXRerqaJI
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.
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/4…
> 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.
