Bruce Momjian wrote:
>
> > I have had the pleasure to work on the guts of one of the major databases
> > raw partition storage managers over the last ten years (hint, not my
> > current domain), and guess what? It implements a file system. And, not a
> > particularly good filesystem at that. Think about something like "FAT",
> > but not quite that nice. It was also a major source of pain in that it
> > was complex, heavily concurrent, and any errors show up as massive data
> > loss or corruption. Be careful what you wish for.
>
> Interesting.
Perhaps we could:
a) Incorporate an existing filesystem into the code (ext2?). By
Incorporate, I mean that we would just take the latest version of the
code and link it into the executable, or into a library and make calls
to some of the lower level access and allocation routines.
b) suggest that for higher performance, the user should format the
disk partition with ext2 (or whatever) and turn off caching and set the
block size to the maximum possible.
I know for a fact that ext2 lets the user select the block size, and
it looks like Linux at least supports a sync mount option which makes
all I/O to this FS synchronous (which I assume would turn off write
caching at least). If caching could be disabled, then option b would
seem to provide performance equivalent to a.
Ocie Mitchell