Greyhole VFS module(s)

[Holger Hetterich]

Am Donnerstag, den 25.11.2010, 17:13 -0500 schrieb Guillaume Boudreau:
> On Thu, Nov 25, 2010 at 16:56, Jeremy Allison <jra at samba.org> wrote:
> > On Thu, Nov 25, 2010 at 03:18:32PM -0500, Guillaume Boudreau wrote:
> >>
> >> Logging to a flat file allows Samba to work even if the actual
> >> Greyhole daemon is offline, for whatever reason.
> >> I didn't want to 'loose' file operations because the daemon was not
> >> running, or worse, prevent users from modifying files when that
> >> happened.
> >> The daemon, when it's running, can then parse those logs at whatever
> >> speed it can, and act on them accordingly.
> >
> > Why go through syslogd then ? Why not have Samba
> > write into a sqllite database, or maybe a transactional tdb
> > that the daemon can access simultaneously if it's running ?
> >
> > Right now you're using syslogd as an intermediate daemon
> > already to linearize the logs. Might be possible to build
> > this into the vfs module.
> 
> Greyhole, when it read the syslog, do some processing and then inserts
> the rows in MySQL (or SQLite; configured in greyhole.conf). So yes,
> cutting the middle-man and inserting directly in the database from the
> VFS module would be very nice.
> Sadly, I'm not proficient enough in C to code this in the VFS module.
> Thus why my module writes in syslog (the simplest C code possible!),
> to be inserted in the DB by the Greyhole daemon.

The sqlite3 C interface is relativly simple, and perfect for the module,
as it could do anything (create the database... etc) on its own. You
would use sqlite3 >= 3.7.0 which allows WAL (Write Ahead Logging), then
you can have multiple readers while a writer (the module) is accessing
the database.


> 
> >> But maybe using both approaches would be beneficial: use a domain
> >> socket when available, and log to syslogd otherwise. When the daemon
> >> would start, it would then need to parse what it missed from the
> >> syslog before starting to accept logs on the socket, in order to keep
> >> the operations ordering (which Greyhole cares greatly about).
> >
> > I just think it's going to be more efficient that going
> > via syslogd -> text file.
> 
> I agree.
> 
> >> But now that I think about it, maybe it would help end-users if Samba
> >> could tell them that the Greyhole daemon is offline, when they try to
> >> modify shared files. They probably don't want the daemon offline.
> >> Do you think it would make sense for the VFS module to return an error
> >> when the socket is not available, and prevent the file operation?
> >
> > Yes, you could do that (return an error). It's part of the VFS
> > interface.
> 
> Is there a specific error that could be returned that could hint the
> user that the problem lies with Greyhole, or at least with one of the
> VFS module? I mean, if I try to write on a Greyhole share using the
> Mac Finder, what are the different errors that I can return in the VFS
> module that would show something specific to the user ?
> 
> >> Sometimes, the daemon needs to be restarted (for example on
> >> configuration changes). I didn't want such restarts to prevent users
> >> writing on their shares...
> >
> > Can you tell me exactly what semantics you require ?
> 
> I'm not sure what you mean by that... Care to rephrase ?

-- 
Holger Hetterich, hhetter at novell.com, 
  SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
   Maxfeldstr. 5, 90409 Nürnberg, Germany