Greyhole VFS module(s)
samba at pommepause.com
Thu Nov 25 15:13:38 MST 2010
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
>> 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.
>> 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
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 ?
More information about the samba-technical