Re: Making metadata storage SQL-driven

On Thu, 2005-09-01 at 12:16 +0200, Christian Neumair wrote:
> I really wonder why we rely on files for our metadata. It has issues [1]
> where a synchronous fopen and read or write operation would really take
> too long, requiring us to schedule reads/writes. Without doing any
> performance measures, I think this could significantly speed up our
> metadata code for big directories. I think we should do the same as
> beagle, and rely on a tiny SQL server, doing all our metadata operations
> synchronously. I'm not a big fan of EAs, since they seem to be some
> different flavors and inconsistencies among various implementations.
> [1]

I don't understand why a SQL server would be any slower than read() and
write(). I mean, it would still end up doing read/write calls. It seems
to me that all it does is highly complicating a simple key/value system.
And furthermore, doing i/o synchronously is definitely a no-no since not
doing that is at the core of the nautilus design.

I'm not saying the current system is great, but I don't see using an SQL
database as a better solution than just fixing stuff to be better.
Databases tend to have all sorts of complications like on-disk format
changes, complexity of installation, opaque file-formats, locking issue
with shared homedirs, fragility (if some part goes bad the whole db can
be corrupt), etc. Furthermore, we wouldn't have much use for most of the
features you get from an SQL database. 

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fast talking playboy paramedic plagued by the memory of his family's 
brutal murder. She's a bloodthirsty foul-mouthed doctor with an evil twin 
sister. They fight crime! 

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]