4 ms·
50 Years in Filesystems: 1974 Unix V7
- senectus1 3y agooi! steady on.. I was born in 1974 and I'm not 50 YET!
- iohead 3y agoWell, V7 UNIX is rather arbitrary as a reference point for comparison. There was what we now call as V1 UNIX, which would be circa 1971/72, so that's certainly 50+ years old. Compared to what's shown in the article, some of the data structure fields and constants would be different and/or missing in the still earlier versions. DIRSIZ would be 8, for example.
- deleted 3y ago[deleted]
- musicale 3y agoWell the author refers to Bach's book (though I thought that was System V?) Another option would be V6 with Lions' commentary.
- musicale 3y ago> There can be only one writer active per file, which kills concurrency Multiple writers contending over a single resource is what kills concurrency. Single writer is a good design. It's also helpful for distributed implementations.
- monocasa 3y agoA file is arguably N resources, where N is the number of granular elements of your file. Probably pages, but could be blocks or bytes too depending on where in storage it's canonical copy lives.
- musicale 3y agoPoint taken. In any case, single-writer helps with concurrency and consistency. For V7 Unix, I think one solution could be to split the file into blocks, each with a single writer. Admittedly this makes reads of the whole file more costly, so one has to be careful about the block size.
- monocasa 3y ago> Admittedly this makes reads of the whole file more costly, so one has to be careful about the block size. Maybe? You're probably locking each block at a time in the buffer cache during reads anyway.
- jasomill 3y agoN.B.: in V7 (and 32V), inodes are locked identically for both writes and reads[1], if((ip->i_mode&(IFCHR&IFBLK)) == 0) plock(ip); if(mode == FREAD) readi(ip); else writei(ip); if((ip->i_mode&(IFCHR&IFBLK)) == 0) prele(ip); I imagine a more serious bottleneck to heavy random-access concurrency on files large enough to be worth splitting would be disk performance, as there's not likely to be a lot of room in physical RAM on a busy PDP-11 or VAX-11/7xx free for buffer caching. And for smaller files able to be serviced entirely from cache, I don't imagine lock contention as a serious issue on a single-processor system like the ones that ran V7/32V. Average seek time / rotational latency (years estimated by manual copyright): RL02 (1978): 55 ms / 12.5 ms RK07 (1978): 36.5 ms / 12.5 ms RA81 (1982): 28 ms / 8.3 ms RA92 (1989): 16 ms / 8.3 ms Note that the RL02 (and V7) and RA92 mentioned in the article are separated by about a decade. [1] https://github.com/dspinellis/unix-history-repo/blob/Research-V7/usr/sys/sys/sys2.c#L64 https://github.com/dspinellis/unix-history-repo/blob/Researc...
- tremon 3y agoBut those N resources are not independent, which is why it makes sense to think of them as one singular resource. For example, if you were to remove the first byte from the file, or prepend a byte, all the other bytes' addresses would change. And arguably, we already have an interface to logically group different filesystem objects together yet retain the ability to address them individually: it's called a directory. I'm sure you could define a more granular format to address all elements within a file individually (for example, a lot of files in a typical Unix /etc directory have rows and fields), but people would call that interface an object store rather than a filesystem.
- aap_ 3y agoA bit strange to talk about 1974 but look at code from v7 (1979).
- rahen 3y agoIndeed. 1974 was the release year of V6, not V7.