Greyhole VFS module(s)

Guillaume Boudreau samba at
Thu Nov 25 13:18:32 MST 2010

On Thu, Nov 25, 2010 at 14:56, Jeremy Allison <jra at> wrote:
> On Thu, Nov 25, 2010 at 02:53:08PM -0500, Guillaume Boudreau wrote:
>> Hi,
>> Jeremy contacted me today about a possible inclusion of the Greyhole
>> VFS module in mainline Samba.
>> I'm thrilled by the idea, so here's the VFS module in question.
>> For those who don't know Greyhole (that would be most if not all of
>> you), you can read about it here:
>> "Greyhole is an application that uses Samba to create a storage pool
>> of all your available hard drives (whatever their size, however
>> they're connected), and allows you to create redundant copies of the
>> files you store, in order to prevent data loss when part of your
>> hardware fails."
>> I have two versions (one for 3.4, one for 3.5) because my 3.4 version
>> wouldn't compile on 3.5. Maybe there's a way to unify both into one
>> file, but I don't know how.
>> Suggestions are welcome. (Code reviews too!)
>> The module is quite simple; it simply logs to syslogd
>> (/var/log/messages) all file operations that Greyhole cares about.
>> Those logs are formated in *-seperated fields: yuck! I'm sure someone
>> can suggest a better approach than this to keep those logs
>> machine-readable!
> Do you have to log these to syslogd ? Is there a better
> way to communicate with Greyhole ? You might want to
> look at the code in modules/vfs_smb_traffic_analyzer.c
> that communicates over a UNIX domain socket to an external
> daemon that logs all Samba traffic. Could Greyhole be more
> efficient using this ?

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.

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

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?

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

More information about the samba-technical mailing list