Such a wonderful blog post on how, through the efforts to replace the mainframe, we all just ended up re-inventing the mainframe.
@vertigo One of my professors in undergrad used to talk about computers moving in cycles. Mainframes to personal computers to clusters back to mainframes. Sequential file storage giving way to fixed allocation file systems to dynamic file systems to object map based file systems. Sequential file systems returned for tape backups and backup software's blocks. Fixed allocation became ISO-9660. And so forth.
@vertigo S3. Or however OS/30 on IBM mainframes implement file systems for virtual machines on the back-end.
There's probably a new term for it these days.
@drwho IBM mainframes use data sets to back both its virtual storage and its Unix filesystem services, which pegs them at fixed allocation units. (Although, they're not quite fixed; MVS and z/OS do allow data sets to grow once they exceed their primary allocation size, if it's configured to do so.)
@vertigo Huh! If I'm reading the Wikipedia page correctly, an IBM data set could be compared to a disk image mounted r/w.
@drwho Yup! I've analogized them as "named partitions" before.
The primary allocation is determined exclusively by hand; secondary extents (if you allow them!) are placed automatically, but even so, their size is determined by hand as well. Both kinds of extents always occupy an integral number of tracks or cylinders as well.
Of course, they are still accessed in terms of records, but those are logical divisions. Set the LRECL to something like 32768 or whatever, and you basically have raw access to a storage partition.
@vertigo You know... that sounds a lot like the filer they had at a place I worked back in '03 and '04. It was called a Shark (not the hostname, the name of the model or line or something). The guy adminning it had to allocate blocks of space by hand and they had to be in whole units, no piecing together the space needed like other filesystems do.
That show had an IBM S/390 in a dinosaur pen (I worked just down the hall from it). Maybe that's what it was?
@drwho I have to admit, I was anticipating something more esoteric than S3. To me, S3 is just a dumb, flat filesystem, mapping names to sequential files. Maybe I'm misunderstanding S3. (My last exposure to it was back in 2013 though.)
@vertigo The way I keep seeing folks use it looks very much like nested hash tables in Python, or how, say, Laravel does disk caching in PHP. server:foo/bar/baz/quux/actual_file.here
@drwho Hmm, not familiar with either, I don't think.
But, according to S3 docs, the key namespace is flat. So any slashes that appear in the filename are treated like any other character, and holds no organizing significance except to the application using that bucket. The S3 console has a built-in "emulation" of folders for convenience, though.
@vertigo I think that's what it is - emulation. Which winds up being close enough for government work.
@vertigo ...and here we are, almost 10 years after that was written: Not only have the users fallen to the Cloud, but companies are trying their best to forget about how to run their own IT in favour of renting applications from Cloud providers.
@galaxis Yup. In principle, I'm okay with this. Not everyone needs to know everything about IT.
In practice, however, I sure wish things had gone a whole lot differently. With extremely rare exceptions, I support the combination of open protocols and the end to end principle.
A bunch of technomancers in the fediverse. This arcology is for all who wash up upon it's digital shore.