Re: [GNOME VFS] Re: Daemons [Was: gob inside gnome-vfs ...]

[Seth Nickell <snickell stanford edu>]

On Thu, 2002-06-27 at 14:04, Maciej Stachowiak wrote:
> On 27Jun2002 12:14PM (-0700), Seth Nickell wrote:
> > On Thu, 2002-06-27 at 02:12, Michael Meeks wrote:
> > > On Thu, 2002-06-27 at 07:19, Maciej Stachowiak wrote:
> > > > That seems like it might be bad for stability - one user-context
> > > > daemon crashing could potentially lead to a lot of data loss if it
> > > > took down all the others.
> > > > 
> > > > But it would definitely make sense to have a single gnome-vfs daemon
> > > > that combined credentials caching, metadata, and whatever other shared
> > > > services would be provided via gnome-vfs.
> > 
> > I think Metadata is less important, we have the same synchronization
> > issues with Metadata that we would with any standard file; that is to
> > say that I'm not sure we need a daemon for metadata and not one for the
> > whole filesystem. 
> 
> The kernel is the daemon for the whole filesystem. It ensures that the
> view of the filesystem is always as if some series of outstanding
> write operations had completed in the correct order.
> 
> Metadata generally involves a read-modify-write cycle, and therefore
> the kernel's guarantees are not enough, and metadata can get lost.
> 
> In fact, we initially thought we could punt on this for Nautilus, even
> though both the main nautilus executable and some out-of-process
> components could change metadata. But we discovered that in practice
> this would result in metadata being lost, so we changed to a model
> where nautilus acts as the metadata server for the components.
> 
> It is this concrete experience that convinces me that metadata
> (without direct kernel-level support) requires a server.

I still don't see how this is different from any other file in the
system, presuming we store metadata as a file. Now it'd be one thing if
we stored all the metadata in a single file, but if we are storing
metadata as a per-file thing on the filesystem anyway...

Now I can understand a potential problem with locking metadata across a
single process, as program using GnomeVFS async might conceivably be
performing a few operations on the file at the same time.

But the problem of multiple processes interacting over a single file
seems, to me, to be the same as the problem (and liklihood) of having
two programs modifying Document.abw or File.txt or whatever at the same
time. That is, there's no obvious reason to me what metadata is more in
need of special locking than any other file. If what the kernel is doing
on the "actual file" is enough already, it should be enough for the
associated "metadata file".

Now if we're dealing with system-wide metadata in a single file, that
might be a different story. There you've agregated the risks of having a
collision together.

-Seth