Re: Making metadata storage SQL-driven

[Jamie McCracken <jamiemcc blueyonder co uk>]

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
> > > commit atomic.
> >
> > 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[1] 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[2] at all.
>
>
> [1] http://lists.mysql.com/mysql/133
> [2] http://dev.mysql.com/doc/mysql/en/multiple-servers.html


to quote:

"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
http://www.advogato.org/person/jamiemcc/