25

SoftwareEngineering.SE has a question about the historically first hierarchical file system (also a similar local question), but what was the first OS with a file system in general?

That is, what OS was the first to abstract the external storage away from physical volumes at the OS level, even by pre-allocated fixed-size chunks, by introducing the notion of a "personal virtual volume" or similar, according to metadata maintained by the OS?

DrSheldon
  • 15,979
  • 5
  • 49
  • 113
Leo B.
  • 19,082
  • 5
  • 49
  • 141
  • 4
    Your question is rather general: Does "external storage" mean random access external storage? or would you consider tape-based and card-based "file" systems? or how about some weird beast like an IBM data cell drive? Must a "personal virtual volume" (PVV) have a name that distinguishes it from other PVVs? Do you require that a program be able to "open" a PVV by name? or is it enough just to be given the already-open "volume" by some JCL command? – Solomon Slow Sep 03 '20 at 19:47
  • 2
    Perhaps you are thinking of the first "use a name to abstract away the underlying media"? – Thorbjørn Ravn Andersen Sep 03 '20 at 20:19
  • @SolomonSlow As far as I am concerned, an OS-level filesystem requires some meta-data maintained by the OS (volume tables, directories, etc). I've updated the question. – Leo B. Sep 03 '20 at 20:21
  • @ThorbjørnRavnAndersen No, volume IDs do not constitute a file system. – Leo B. Sep 03 '20 at 20:22
  • @LeoB. Not volume ids but a name to indicate a very specific set of chunks of the volume constituting the file. I would guess you need something more modern than cards provided by an operator before names known to the computer became necessary. – Thorbjørn Ravn Andersen Sep 03 '20 at 20:25
  • 2
    Maybe I misunderstand the question, but why do you require the OS "to abstract the external storage away from physical volumes"? MS-DOS and the versions of Windows built upon it still very much used physical volumes ("disk in drive A:", "hard drive C:", rather than, say "/mnt/fdd"), and yet FAT is undeniably a file system. – Michael Graf Sep 03 '20 at 20:39
  • @ThorbjørnRavnAndersen - card files need names too. Consider an OS with multiple input devices. A program requests "document X". Before or after that instant in time, the operator/user loads the cards in any one of the available card reader and presses "engage" which causes a device interrupt. The card deck starts with a card proclaiming it to be "document X", so the OS can match the input file with the program request. Spooling is possible but not required in this scenario. – dave Sep 03 '20 at 20:45
  • @another-dave I'm not old enough to know these things. 8" drives was my first. – Thorbjørn Ravn Andersen Sep 03 '20 at 20:47
  • @MichaelGraf in MS-DOS, it was possible to open a file without mentioning the drive, by virtue of the notion of "current drive". – Leo B. Sep 03 '20 at 21:10
  • @LeoB.-- yes, of course, but that doesn't mean that the OS abstracted away physical volumes. They were still very much there, with each physical volume having its own, separate file system, in contrast to, say, the Unix approach, where you have one all-encompassing logical file system in which you then mount the contents of physical volumes in more or less arbitrary places. – Michael Graf Sep 04 '20 at 09:22
  • 1
    I think "metadata maintained by the OS" is the sole difference between a file and a file system. Anything that reduces the burden on the operator. A volume ID should qualify, or even just an end-of-file marker, if the OS explicitly put it there. – snips-n-snails Sep 04 '20 at 14:33
  • I'm not sure that there are any operating systems that have filing systems. Surely in all OSs, the FSs are outside the kernel and therefore not part of the OS itself. – Chenmunka Sep 04 '20 at 17:28
  • 1
    @Chenmunka A user process does not care about the architectural details. All functionality provided by it via system calls is the OS functionality. – Leo B. Sep 04 '20 at 17:54
  • @MichaelGraf From a user process perspective, being able to request access not to a raw media on a physical drive, not to the whole volume by ID on whichever drive at the moment, but to a named object of finer granularity than a volume by virtue of some persistent OS metadata, is a level of abstraction. The difference between the MS-DOS approach and the Unix approach in file naming is superficial, given the ability of MS-DOS to assign drive letters to directories and vice versa – Leo B. Sep 04 '20 at 18:11
  • @Chenmunka - see, for example, TOPS-10. The file system implementation for disk volumes, DSKSER if I recall correctly, is part of the resident monitor (='kernel', as the kids today call it). Also, you are conflating 'OS' and 'kernel', they are not the same thing. – dave Sep 05 '20 at 16:29

2 Answers2

19

My second guess is CTSS. It was operational in 1961, but at that time had only tapes for user file storage. I suppose that tape name records don't constitute 'metadata' in the sense required by this question.

A disk was added somewhere around 1962 to 1963. The CTSS Programmer's Guide from 1963 mentions

  1. the installation of the IBM 1301 disk file; and 5) the design and programming of a master disk control subroutine (memo CC-196) and an associated disk editor program (memo CC-208)

I have not found CC-196 online, but CC-208 describes the Master File Directory (MFD), User File Directories (UFDs). Each UFD entry contains the starting track number and number of tracks for the file; I infer files are contiguous.

(Page 1 if you want to look it up; it doesn't cut and paste well)

So, this definitely qualifies as a file system within the requirements of the question. It also demonstrates a pleasing ancestral relationship to the subsequent hierarchical filesystem paper. Whether CTSS was 'first' depends on whether anyone else here can find anything earlier.

dave
  • 35,301
  • 3
  • 80
  • 160
  • Thank you! That's a very plausible guess, given that CTSS was "one of the first" time-sharing systems, where virtualizing storage makes perfect sense. Let's see if anyone comes up with anything earlier. – Leo B. Sep 04 '20 at 03:09
  • 1
    @LeoB. You almost got me thinking, "Of course! What good would a time shared system be without files?" but then I remembered my first computing experience: Dial-up to a time shared system running BASIC. Maybe it had support for files, but if so, then my school's login privileges were not sufficient to create any. If we wanted to save a program we'd typed in, our only option was to LIST it, and capture the listing on paper tape. – Solomon Slow Sep 04 '20 at 15:07
  • 1
    Dartmouth Basic definitely had files, and possibly right from the beginning, as far as I can tell. But it appeared in 1964, after CTSS already had its full file system. – RETRAC Sep 04 '20 at 15:25
  • @SolomonSlow - ditto (dialup to Open University, courtesy of my maths teacher who was taking an OU computing degree) – dave Sep 04 '20 at 16:30
  • 1
    The IBM 305 offered a computer with a hard drive in 1956. I don't know whether it came with a file system.
    IBM 305 RAMAC     – Walter Mitty Sep 05 '20 at 11:03
  • 1
    @WalterMitty - no operating system, no assembler, so very likely no file system either :-) Programming manual – dave Sep 05 '20 at 16:33
  • The other day a friend of mine, when asked the question, had guessed CTSS as well. – Leo B. Sep 07 '20 at 20:30
11

(This answer has now been determined not to satisfy the now-clarified requirements of the question. Nevertheless, the discussion seems useful, if only in my own mind, so I will leave it here. But see my other answer about CTSS.)

I will guess that the standard answer for 'first' applies here: the Atlas Supervisor.

Section 6 of the linked document talks about data handling.

The fast computing speed of Atlas and the use of multiple input and output peripheral equipments enable the computer to handle a large quantity and variety of problems. These will range from small jobs for which there is no data outside the program itself, to large jobs requiring several batches of data, possibly arriving on different media. Other input items may consist of amendments to programs, or requests to execute programs already supplied. Several such items may be submitted together on one deck of cards or length of punched tape. All must be properly identified for the computer.

To systematise this identification task, the concept of a document has been introduced. A document is a self-contained section of input information, presented to the computer consecutively through one input channel. Each document carries suitable identifying information (see below) and supervisor keeps in the main store a list of the documents as they are accepted into the store by the input routines, and a list of jobs for which further documents are awaited.

This is perhaps more dynamic than you had in mind; the supervisor only maintains identification/location information for 'active' files. However, I think this is not so very different to systems using exchangeable disc storage; the OS often only knows the content of what's currently mounted online - unless of course it has the design that maintains a single catalogue for all volumes.

The important feature that makes this a valid answer is that the user assigns a name to the document, the program asks for the document by name, and the supervisor uses the name to match the program request to the hardware on which the document lives (which might, transparently, be on magtape if input spooling is being used).

dave
  • 35,301
  • 3
  • 80
  • 160
  • 2
    Another first for the Atlas ;-). – Stephen Kitt Sep 03 '20 at 20:58
  • 5
    There are only two answers needed in this entire forum: 'Atlas' and 'IBM Stretch' :-) – dave Sep 03 '20 at 21:00
  • 1
    That would be a good answer to the question "which OS first had the notion of a file", but my question was about a file system. Note that in your case there is no metadata maintained by the OS. – Leo B. Sep 03 '20 at 21:15
  • 4
    Document-name-to-device mapping sounds like metadata to me. (Not sure whether they spooled to drum; I think probably not). – dave Sep 03 '20 at 21:26
  • 1
    But what do you imply by 'file system'? Does it have to be magnetic media? Rewriteable? Random access? Directory-structured? Would a DECtape (or its predecessor the LINCtape) fit the requirements? – dave Sep 03 '20 at 21:28
  • The passage that you quote sounds like a description of a self-contained batch job, and the "documents" to which it refers sound like they are embedded in the job deck/tape: "A document is a self-contained section of input information, presented to the computer consecutively through one input channel." – Solomon Slow Sep 03 '20 at 21:50
  • The "self-contained" part means one document must be on one input device with all the records together, not split across devices and not in multiple parts on a single device. But a job could reference multiple documents (obvious case: cards + papertape). Elsewhere in the Atlas write-up it specifically says that documents for a job can be entered on multiple devices; the supervisor tracks them by name. And I think that's the conceptual novelty here; once you have named documents, it's obvious what to do when disc hardware shows up. – dave Sep 03 '20 at 22:12
  • @another-dave It has to be media capable of storing metadata produced by the OS to describe sub-volume-sized storage objects addressable and accessible by the user program.That makes it re-writable, magnetic (I guess; what other re-writable external media of the era were there?), but not necessarily random access. LINCtape would do, if it is the first. – Leo B. Sep 03 '20 at 22:51
  • What year did this appear? – Stig Hemmer Sep 04 '20 at 08:01
  • It's difficult to pin an exact date on it, since the hardware and software were being designed and developed simultaneously. System design complete in 1959. Final supervisor in 1964. Was in service from 1962. Most papers are from 1962. What do you mean by 'appear'? Design, implementation, available to users? – dave Sep 04 '20 at 11:27
  • This doesn't seem much like a filesystem. It sounds more like temporary, job-specific names for portions of the input media associated with a particular batch job. – Barmar Sep 04 '20 at 16:10