Hacker News Reader

Comment by veltas | Hacker News Reader

A point being overlooked by article and commenters: the records in the registry probably use in the order of 10-100 bytes each, while every actual file takes up at least around 1024 (EDIT: maybe more like 4096?) bytes. Putting tiny 'files' into a special format is a no-brainer on the older computers that existed when the Registry was first created. I am assuming this was one of the motivations to create the Registry in the first place, to save space.

View on HN

Extracted from the "Rationale" section of https://en.wikipedia.org/wiki/Windows_Registry

1) Since file parsing is done much more efficiently with a binary format, it may be read from or written to more quickly than a text INI file.

2) Strongly typed data can be stored in the registry, as opposed to the text information stored in .INI files.

3) Because user-based registry settings are loaded from a user-specific path rather than from a read-only system location, the registry allows multiple users to share the same machine, and also allows programs to work for less privileged users.

4) Backup and restoration is also simplified as the registry can be accessed over a network connection for remote management/support,

5) It offers improved system integrity with features such as atomic updates.

These points are mostly bogus IMO, but apparently this was their initial rationale for implementing it.

Almost nobody mentions another rationale or use case: the registry is accessible from kernel mode. This makes it, in addition to the other things, kind of analogous to sysctl.

> These points are mostly bogus IMO

Why?

I don't really see a reason to believe this list is comprehensive, especially looking at the sources.

On ext4, a file of 160 bytes or less (and no xattrs) can be stored inline in the inode[1], so the whole thing takes up 256 bytes (plus 8 + [length of filename] for the directory entry). I don’t think any Unix filesystem did that in 1989, but the problem is not unsolvable, especially given that you are hardly going to use a configuration file to store a single value. NTFS does the same, actually, except it can’t count that low, so you get 1K.

(Of course, before there was the registry there were the textual CONFIG.SYS and WIN.INI, but those were shared and would be easily corrupted by programs trying to modify them manually, which I suspect the registry is a reaction to.)

[1] https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inli...

> On ext4, a file of 160 bytes or less (and no xattrs) can be stored inline in the inode[1], so the whole thing takes up 256 bytes (plus 8 + [length of filename] for the directory entry).

It can if you enable an option that is not widely used, IIRC.

Huh, right you are: the inline_data feature is from 3.8 (2013), but apparently tune2fs couldn’t enable it on a live filesystem for some time after that, and it’s still not on by default.

(I remembered seeing the feature in the format description, but did not think it would actually be unused in most cases.)

I'm trying to remember Win95 on FAT32 (or exFAT?)... on a large hard disk, wasn't the smallest file size 32KB or 64KB?

Different times...

I could swear this was the cluster size for FAT32 on a 2G drive, but apparently not[1], this is the cluster size for FAT16 on 2G. FAT is just utterly dumb in how it does space allocation: it doesn’t even have a bitmap, it’s just a gigantic dense array of linked list nodes (the eponymous file allocation table). Perfectly fine for a 360K floppy on a 32K machine, predictably painful for a 2G hard drive on a 32M machine. Add in narrow allocation unit (“cluster”) numbers, and you end up with huge allocation units.

As far as I can see, ext2/3 instead use a free bitmap and a tree-style “indirect block” setup that is recognizably similar to (though greatly extended from) V1 UNIX (1971) [2], predating even the original FAT8 (1977). Ext4 can do extent [that is, (start, end) pair] allocation instead, and XFS, ZFS, Btrfs, etc. are built around it. Thus they can and actually do manage disk space in smaller bits.

[1] https://support.microsoft.com/topic/default-cluster-size-for...

[2] http://squoze.net/UNIX/v1man/man5/fs or https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

I was going to say that even the 5150 shipped with 256K, but I checked Wikipedia and they say the minimum spec was 16K. Which is astounding.

>NTFS does the same, actually, except it can’t count that low, so you get 1K.

Not exactly, a $MFT record (on 512 bytes/sector media) is 1024 bytes, the most you can store in it (it slightly varies depending on the length of the filename and on the exact way the file is written) is 744 bytes max.

On 4K disks, the $MFT record is 4096 bytes and allows up to 3776 bytes max.

JFYI:

https://www.forensicfocus.com/forums/general/mft-resident-da...

Good perspective. It’s easy to lose track of that as enough time has passed that the parents of commenters were in high school when this was implemented.

One time perspective thing to keep in mind is that the IBM mainframe was younger to the folks doing this work at Microsoft than we are to the Microsoft people today. Their constraints were different and the diversity of end users was very different.

Even with years of experience and advancement, in Linux we moved configuration to systemd, which is exponentially better than the registry but also more complex. Complicated configuration systems will always have pros and cons.

However, by default on NTFS, there will be 4096-N bytes of used space each time the specific hive needs to grow to accommodate those 10-100 bytes (this varied historically if we're talking about NT 4 and below, depending on volume size) due to format cluster size.

That said, it is still smaller than 100 files that are 10-100 bytes each taking up 4096 bytes, though with NTFS, those would be stored in the MFT anyways...

I should add to this, as we know file system filters (e.g., anti-virus) slow down access to read (and write, but irrelevant here) files from any file system format on Windows (NTFS, FAT32, exFAT, etc), storing configuration data in configuration files would be less optimal, though minimal in terms of performance (given your app wasn't constantly re-reading the file). This wouldn't be the case with the Registry, as the hives are already open.

That overhead is not intrinsic to the concept of a filesystem. If you asked someone to design a filesystem specifically to store short strings they could easily come up with a low-overhead design while preserving the other advantages of real filesystems.

ReiserFS could do this ...

Nobody in their right mind would put every field into a separate file though. (Yes, I do know about qmail.)

Yes but that is the comparison being made, that the registry is like a filesystem and thus should have just been a filesystem. If the suggestion is to put many fields in one file then that's a different suggestion.

There have been filesystems that don’t use strict block sizes - Reiser4 IIRC. It’s not done often because the savings are tiny and it complicates implementation a lot.

A bigger problem I can see is that Unix file system semantics is… hairy; see rename(2) atomicity guarantees for example. So it could make sense to replace it not with a typical filesystem, but something more RESTful.

Again, the filesystem in context was the Windows filesystem, not a UNIX filesystem or Reiser4.

Reply on news.ycombinator.com