3 ms·
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]
by 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 agoHuh, 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 agoI'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 agoI 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
- tadfisher 4y agoI 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.
- jaclaz 4y ago>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-data/ https://www.forensicfocus.com/forums/general/mft-resident-da...