Still, it was an amazing achievement for nonetheless relatively affordable PDP-11/45, on which it was eminently usable, and in many ways better than anything else out there aside from it's Multics forefather.
(Originally ran on a first generation PDP-11, later the 11/20, with an extra memory unit so it could run split Instruction and Data (I&D) and have decent budgets for both; on the 11/45, that would be up to 64KiB code, 56KiB data, and 8KiB stack.)
And they ran that system on a machine with 144kB of RAM, where desktop CPUs have had more Level-2 cache than that for years now.
And by now, as somebody else kindly points out, high end server CPUs approach Level 3 caches as big as the hard drive their system ran on... (I think zSeries CPUs have level 3 or level 4 caches in the 128MB range, so their caches actually are bigger than that.)
Will write that in one of my upcoming research papers and see how it turns out.
14 bytes for filename, and as I recall 2 for the inode in that particular filesystem, so a total of 16 bytes per directory entry. I'm not sure what the typical minimal disk space budget was, but assume as little as 5 MiB, e.g. 2 RK05s, so you had to make every byte count. On a student run computer center I started with the Logo Lab's surplus PDP-11/45, we considered ourselves very lucky to have scored the prototype CONS Lisp Machine's CDC SMD 80 MiB (unformatted) drive to run the system on. Note that the latest Haswell Xeon CPUs are getting up to a max of 45 MiB L3 cache....
What was much worse was that many programs just opened directories as files (which of course they are) and assumed that format, which caused more than a little pain when we moved to bigger machines and more sophisticated filesystems.
