OS's with loadable filesystem support 2398
raw was to avoid standard unix filesystem caching and poor consistency. with raw ... the dbms had a pretty good idea of what was actually on disk and what was actually in memory and when there were transitions between the two. raw useage predates 32bit addressing limits becaming a limitation.
for decades, unix filesystems had been notorious for their extremly poor disk surface consistency operation. you have a filesystem that couldn't satisfy acid properties ... and, in turn, it was difficult to create a dbms that would use standard filesystem operation and still satisfy acid properties.
OS's with loadable filesystem support 2399
slightly related post on issues of disk use in os-360 however, one of the other things...
the later generations of journal-logging unix filesystems tended to be just for filesystem metadata ... to somewhat avoid loosing the whole system because of filesystem corruption ... but still tended to retain traditional unix filesystem inconsistency characteristics for actual file data (distinct from filesystem meta-control data).
random search engine reference for acid properties
for a little topic drift ... system-r was the original relational-sql implementation
and one of the consumers of global lock manager for ha-cmp
was distributed database operation,
one of the things that posix (async) i-o attempted was to provide ability to use standard filesystem allocation-deallocation of disk surface but perform direct i-o (reads and writes) with direct control between the disk surface and processor memory space (bypbutting most of the standard unix filesystem operations). posix i-o can be intertwined with memory mapped operation.