Point 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.

> 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.

N.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 random read/write concurrency would have been disk performance.

Average seek time / rotational latency (years by manual copyright, so estimated):

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/Researc...

But 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.

They are independent, just their assignment to addresses is not. That's why databases still gain from having multiple writers with the exception of SQLite.

But those interfaces [to allocate bytes/pages before other bytes/pages, allocate bytes/pages in the middle of bytes/pages, to prune bytes/pages before other bytes/pages] to manipulate said parts are non-portable between *NIX implementations, usually limited to certain filesystems with specific implementation-specific minimum byte sizes.

So like how the OS pretends filesystems are in a tape, the filesystem pretends that the files are in a tape.

And tape splicer is optional with a not-standard interface (logical volume management, fallocate, etc).

Then don't do that part, allocate at the end and only rewrite existing blocks rather than deleting them. It's like how just because you can't easily sbrk(2) new memory before at the beginning of a heap doesn't mean you can't have multiple threads despite that being the resource you're contending.