Re: Making metadata storage SQL-driven
- From: Jamie McCracken <jamiemcc blueyonder co uk>
- To: Alexander Larsson <alexl redhat com>
- Cc: Christian Neumair <chris gnome-de org>, nautilus-list gnome org
- Subject: Re: Making metadata storage SQL-driven
- Date: Thu, 01 Sep 2005 13:00:57 +0100
Alexander Larsson wrote:
On Thu, 2005-09-01 at 12:36 +0100, Jamie McCracken wrote:
Alexander Larsson wrote:
On Thu, 2005-09-01 at 12:21 +0100, Jamie McCracken wrote:
For instance the embedded mysql needs no set up and it will work out of
the box (its just a shared library) so installation and setup is a
non-issue. It has no locking issues as the INNODB stuff in mysql is
multi generational so readers and writers dont block each other and its
totally safe as a write generates a new copy of a record and the commit
on it is atomic so even of there's a power failure during a write
corruption will not occur to anything committed.
How does this work with shared NFS homedirs? Writes are not atomic there
the same way they are for local filesystems, so how could you make the
I dont know the internal details of mysql but generally casue the
generation architecture is journalised a new write creates a copy of the
exisiting record which once completed will have a flag on the record to
indicate whether its committed or not. So once the user has written the
changes, the user will call commit to set that flag. If power failure
occurs the record will either be committed (the flag set) or not (in
which case that copy is discarded and lost forever). To benefit from
this forced writes need to be used.
This is all true for a local filesystem (well, given a journaling
filesystem to cleanly handle the power failure), however it doesn't seem
to apply to NFS. You can't atomically extend the file over NFS (to my
knowledge). Say the file is now 1000 bytes, if two separate machines
wants to extend the file at the same time they'll both send a "write
this block at offset 1000 packet to the NFS server. The last one to the
server wins I believe. So, updates will be atomic on each client box,
but not between different boxes.
It seems that mysql does correctly handle one writer and multiple
read-only instances over NFS, but that doesn't cover this usecase.
Overall, mysql doesn't seem to be recommending the use of databases on
NFS at all.
"Allowing multiple MySQL servers to access a common data directory over
NFS is a bad idea!"
yes but thats not the case here is it?
Firstly we are not dealing with a mysql server yet alone multiple ones
and secondly only one instance (albeit with multiple threads) would ever
access the data files in a user's home directory so im not sure this is
an issue. The threads would mutex access so it should be a non-issue, yes?
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a one-legged misogynist messiah She's a man-hating kleptomaniac opera
singer living homeless in New York's sewers. They fight crime!
Mr Jamie McCracken
] [Thread Prev