FAT32 is not a very fast filesystem. Things like caching are necessary to make it performant. Also, the IO subsystems in Win98 sometimes chose slow paths or interfaces.
Yes caching was required but that was as much to work around slow storage mediums (as was the norm back then) and in fact that capability is built into the OS rather than the file system and is used by all file systems. This is the same for Windows 9x, NT, and even Linux and UNIXes too (ZFS on Linux is the one exception I know of where caching happens within the file system driver).
Sure, Win 98 might might a few IO optimisations, I think DMA might even be disabled by default, but it’s also a much lighter OS than modern contemporaries and that will make a hell of a difference too. Remember 98 was designed to run on hardware less powerful than a 10 year old smart phone and the entire OS has a install footprint of around 300MB. There’s going to be less background processes (and particularly on a VM install specifically for Delphi 2 benchmarks). The only draw back is you wouldn’t have SMP; but that doesn’t always help with software compilers because they are traditionally single threaded processes.
BTW, Windows benchmarks tend to follow same pattern of FAT32 being slower than newer filesystems. [2][3][4]
[0] https://www.phoronix.com/scan.php?page=article&item=linux_us...
[1] https://web.archive.org/web/20010627181258/http://bulma.lug....
[2] https://www.flexense.com/fat32_exfat_ntfs_usb3_performance_c...
[3] https://www.sami-lehtinen.net/blog/exfat-fat32-ntfs-real-lif...
[4] https://www.tomshardware.com/reviews/ssd-file-system-ntfs,31...
Running sqlite3 on a USB stick isn't really the same as one time sequential read from a virtual hard disk though. Even FAT32 on Windows 98 could handle sequential reads just fine. In fact if you look at the other benchmarks in that link you supplied -- the ones that are doing tasks more equivalent to a compiler -- FAT32 actually comes out pretty fast.
> but some older benchmarks [1] also show noticeable performance differences, especially when the workload is more meaningful than copy files.
But the workload in question isn't more meaningful. A compiler is "just" reading a few files and then writing a few new files. It's going to be more CPU and memory intensive than disk heavy.
> Lack of features does not imply efficient design.
I'm never suggested it does. However for simple workloads like a sequential read and write from a virtual hard drive where your host has already abstracted away the problems of physical hardware with optimised drivers, a lack of features on the guest operating system could conceivably be a more efficient design. It's not that far fetched a comment given that's the principle behind unikernels.
> Caching was optional with Windows 98 and sometimes was turned off by default
It's optional in every OS (even now) but is rarely ever turned off by default under normal operating conditions -- this is as true for Windows 98 as it is for Linux.
> The referenced Linux benchmarks probably limit the variability here since I think Linux tends to follow the same code paths, independent of the partition types.
There's a few things to consider when looking at these file system benchmarks:
1. They are all running on Linux so none of them actually demonstrate the FAT32 driver in question
2. They're writing direct to physic media (which isn't the case with the Delphi 2 benchmark).
3. The workload you're demonstrating isn't equivalent to the workload of a compiler. I wasn't suggesting people should run databases on FAT32 (tbh I wasn't suggesting people should run FAT32 at all).
I would be interested in the same Delphi 2 benchmark but with Delphi running bare metal in WINE