Marko Kreen wrote:
>
> On Sat, May 05, 2001 at 01:09:38PM -0400, mlw wrote:
> > A small debate started with bad performance on ReiserFS. I pondered the likely
> > advantages to raw device access. It also occured to me that the FAT file system
> > is about as close to a managed raw device as one could get. So I did some
> > tests:
>
> > /sdb1 is either an ext2 or FAT file system used as "pg_xlog" with a symlink.
>
> One little thought: does mounting ext2 with 'noatime' makes any
> difference? AFAIK fat does not have concept of atime, so then
> it would be more fair? Just a thought.
>
> --
> marko
I don't know, and I haven't tried that, but I suspect that it won't make much
difference.
While I do not think that anyone would seriously consider using FAT for xlog,
I'd have problems considering myself, it in a production environment, the
numbers do say something about the nature of WAL. A bunch of files, all the
same size, is practically what FAT does best. Plus there is no real overhead.
The very reasons why FAT is a POS file system are the same reasons it would
work great for WAL, with the only caveat being that fsync is implemented, and
the application (postgres) maintains its own data integrity.
Oddly enough, I did not see any performance improvement using FAT for the
"base" directory. That may be the nature of the pg block size vs cluster size,
fragmentation, and stuff. If I get some time I will investigate it a bit more.
Clearly not everyone would be interested in this. PG seems to be used for
everything from a small personal db, to a system component db -- like on a web
box, to a full blown stand-alone server. The first two applications may not be
interested in this sort of stuff, but last category, the "full blown server"
would certainly want to squeeze as much out of their system as possible.
I think a "pgfs" could easily be a derivative of FAT, or even FAT with some
Ioctls. It is simple, it is fast, it does not attempt to do things postgres
doesn't need.
