> > So what is needed it to be able to mount a .zip or a .tar file as a file
> > system with the loopback device. Mounting a database on the filesystem
> > sounds pretty useless to me.
>
> Raw disk access allows:
>
> 1) removing the double buffering problem associated with read/write + shm
> 2) your own filesystem semantics and explicit block flushing versus whole
> file flushing (fsync)
> 3) removing layers of abstraction, you loose the FS abstraction and allow
> the database abstraction to take over which shortens the code path
> and gives complete control over the data to the database.
>
> However it limits:
>
> 1) doing backups, you must either have a utility that can read the
> 'dbfs' or use 'dd' to copy the entire disk.
> (this is ok, we have pg_dump)
> 2) taking advantage of built in filesystem advantages like snapshots,
> logging and other advanced features.
> (only things i can think of is snapshots to make an immediate backup
> but then again we have pg_dump as well as filesystems that can grow)
> 3) portability, not all OS's support character devices, the ones that
> don't can't safely guarantee data write ordering.
> 4) development time, as the database now has a filesystem module
> to maintain.
>
> I'm sure there's a few points that I missed but there are some
> advantages, Oracle does or did have a "raw disk" mode.
>
I think the conclusion we came up to in the past is that raw database
access was important in the 80's with older file systems, but modern
ones don't need raw access, and most database vendors are moving away
from recommanding raw access.
[ FYI, Linux ext2 is not a modern file system.]
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
