Greyhole VFS module(s)

[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.

>> 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 ?