TIL that early Unix (before V4) had 8-byte filenames, instead of the 14-byte ones that were V4 onward, despite this not fitting an even number of directory entries into power-of-two sized disk blocks.

(Early Unix directory entries are a two-byte inode number plus the filename, not necessarily null terminated. Yes, this does have the maximum inode limit for a single filesystem that you think it does.)

@cks

Off By One Error in your post on this. (-:

Since 0 means a free directory entry, that's only 65535 i-nodes.

Mind you, at 8 i-nodes per block, you'd come close to the size of some contemporary discs with a maximally sized i-node table.

#Unix #filesystems

@JdeBP Oh true, I didn't think of the inode 0 issue. I believe inode 0 existed but was unusable as a directory entry, which must have started at 1 for the filesystem's root (which couldn't be 0 because of '.'). I wonder if early Unix ever used inode 0 for anything clever, or if it just sat there.

@cks

The same thought occurred to me. There have been cute tricks like that played. I've even played some of them on other systems.

But as far as I know that first entry in the i-node table was just unused.

I wonder whether fsck even checked it. Modern FreeBSD fsck_ffs does, but that's a very different beast.

#Unix #filesystems #FFS #UFS

@cks

Which in turn then prompts the question of whether one with suitable chicanery could set it up as a correct i-node which fsck would consider allocated, but that would be unfixable.

Presumably the reference counting checks would detect it as an an orphan, but putting a directory entry referencing it in lost+found would not work.

Assuming that the reference counting pass does not also have a < ROOTINO short-circuit in the code too. (-:

#Unix #filesystems #FFS #UFS #FreeBSD