On 1/9/07 10:17 PM, Tony Abernethy wrote:
chefren wrote:
On 1/9/07 1:22 PM, Richard P. Welty wrote:
..
yes, it seems to me that the author of this proposal doesn't really
understand the huge gap between a conventional file system and
a full up RDBMS.
I do.
You don't.
I do.
How do you handle physical defects in the storage media?
Not, hardware should work, it may handle defects itself and when it's
defect you should drop it.
How do you store the RDMS inside the RDMS?
NOT!!!
You don't get the basic idea and seems to prefer inaccessible data blobs.
How do you bring up the RDMS from a cold start on the bare hardware?
What about using the bootsector like now?
How do you determine which attributes exist and how big each is?
Why is this a problem?
Once that is done, how do you add attributes or change their sizes?
Your brain is "filed", why is this a problem, storing attributes is
done perfectly by databases and BAD by files, since about only the
program that stores them knows what are the attributes.
..
Then explain to me what a good file system is!
I can lose a sector without losing the entire disk.
That's no problem, I propose a database filesystem that has integrated
versioning and replication. If a drive fails you can go on with a copy.
If the filesystem is damaged I can recover information from it.
Clumsy.
Not only that, but I can actually use a disk that is not 100% in a
production environment. (Disks have effectively been that way for a long
time)
Disks are approaching 1TB these days, your "recovery" should be there
instantly or you are busy 1000x 1 minute to restore (from what???) and
that's impossible if you don't have a replicated version of your data
on a hot spare.
Filesystems need versioning and replication =build in=, you cannot
backup a 750G harddisk now and then, these days everything is "on
line" and you need continous copies on multiple locations.
How do you "version" the boot sector?
Childish
Restoring a 750GB disk (who has tapedrives to store 750G?) costs about
a minute a GB, clueless path.
With or without error recovery?
Without! If a disc is broken it's broken, throw it away!
And a filesystem with true versioning and replication is as close to a
database as you can get.
What is this "true versioning"?
That you can restore earlier versions of data.
How does it differ from whatever whoever happens to call "versioning"?
What is the granularity that distinguishes one version from the next?
Both versioning and replication need paramaters. You can wish to store
every write and consider a write only done when it's fully replicated
on another disk but laws of physics would make that a very dependable
but relatively slow solution.
> Why?
One of the driving forces behind my wish for a database filesystem is
that disk space is cheap but hard to backup and we are in need for a
clear solution.
+++chefren
