Re: MySQL file system

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Joseph Shraibman <jks(at)selectacast(dot)net>
Cc: Karl DeBisschop <karl(at)debisschop(dot)net>, Ned Lilly <ned(at)greatbridge(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: MySQL file system
Date: 2001-01-17 03:43:42
Message-ID: 20010116194342.G7240@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

* Joseph Shraibman <jks(at)selectacast(dot)net> [010116 19:29] wrote:
> Karl DeBisschop wrote:
> >
> > Ned Lilly wrote:
> > >
> > > Anyone heard about this?
> > >
> > > http://no.spam.ee/~tonu/mysqlfs.html
> >
> > I was bout to copy about 3000 RFCs onto my hard drive last night.
> > Bowsing them online was just too painfully slow.
> >
> > Then I realized that although I had the disk space for the total file
> > size, they were mostly smaller than a block on my disk, so I was going
> > to loose alot of space.
> >
> > My first thought was, well postgress would stor that as one file - that
> > might work. Then I thought "I'm trying to be FAST here -- any time spent
> > on this is a distraction. Too bad there is no such thing as
> > PostgreSQL/FS"
> >
>
> 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.

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Miller 2001-01-17 03:52:06 Re: >>>>> pg_dump in crontab
Previous Message Iwan Tutuka Pambudi 2001-01-17 03:30:47 >>>>> pg_dump in crontab