4 ms·

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

by veltas 4y ago

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.

Spooky23 4y ago
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.
trasz 4y ago
Nobody in their right mind would put every field into a separate file though. (Yes, I do know about qmail.)
- veltas 4y ago
  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.
  - trasz 4y ago
    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.
    - veltas 4y ago
      Again, the filesystem in context was the Windows filesystem, not a UNIX filesystem or Reiser4.
osigurdson 4y ago
Extracted from the "Rationale" section of https://en.wikipedia.org/wiki/Windows_Registry 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.
- asveikau 4y ago
  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.
- lupire 4y ago
  > These points are mostly bogus IMO Why?
- veltas 4y ago
  I don't really see a reason to believe this list is comprehensive, especially looking at the sources.
trevorishere 4y ago
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...
- trevorishere 4y ago
  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.
mananaysiempre 4y ago
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#Inline_Data https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inli...
- temac 4y ago
  > 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.
  - mananaysiempre 4y ago
    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.)
- Tempest1981 4y ago
  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...
  - mananaysiempre 4y ago
    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-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95 https://support.microsoft.com/topic/default-cluster-size-for... [2] http://squoze.net/UNIX/v1man/man5/fs http://squoze.net/UNIX/v1man/man5/fs or https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf
wmf 4y ago
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.
- rwmj 4y ago
  ReiserFS could do this ...

by veltas 4y ago

Spooky23 4y ago

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.

trasz 4y ago

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

veltas 4y ago
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.
- trasz 4y ago
  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.
  - veltas 4y ago
    Again, the filesystem in context was the Windows filesystem, not a UNIX filesystem or Reiser4.

osigurdson 4y ago

Extracted from the "Rationale" section of https://en.wikipedia.org/wiki/Windows_Registry 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.

asveikau 4y ago
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.
lupire 4y ago
> These points are mostly bogus IMO Why?
veltas 4y ago
I don't really see a reason to believe this list is comprehensive, especially looking at the sources.

trevorishere 4y ago

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

trevorishere 4y ago
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.

mananaysiempre 4y ago

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#Inline_Data https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inli...

temac 4y ago
> 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.
- mananaysiempre 4y ago
  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.)
Tempest1981 4y ago
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...
- mananaysiempre 4y ago
  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-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95 https://support.microsoft.com/topic/default-cluster-size-for... [2] http://squoze.net/UNIX/v1man/man5/fs http://squoze.net/UNIX/v1man/man5/fs or https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf https://www.bell-labs.com/usr/dmr/www/pdfs/man51.pdf

wmf 4y ago

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.

rwmj 4y ago
ReiserFS could do this ...