[libvirt] filesystem recognition [was: [PATCH] util: recognize SMB filesystems as shared]

[Jim Meyering]

On Thu, Sep 26, 2013 at 7:33 AM, Eric Blake <eblake at redhat.com> wrote:
> [actually adding coreutils]
>
> On 09/26/2013 08:28 AM, Eric Blake wrote:
>> On 09/26/2013 03:43 AM, Laine Stump wrote:
>>> This should resolve:
>>>
>>>   https://bugzilla.redhat.com/show_bug.cgi?id=1012085
>>>
>>> libvirt previously recognized NFS, GFS2, OCFS2, and AFS filesystems as
>>> "shared", and thus eligible for exceptions to certain rules/actions
>>> about chowning image files before handing them off to a guest. This
>>> patch widens the definition of "shared filesystem" to include the SMB
>>> filesystem (sometimes called CIFS, or "Windows file sharing").
>>> ---
>>>  src/util/virstoragefile.c | 9 ++++++++-
>>>  src/util/virstoragefile.h | 1 +
>>>  2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> Coreutils includes a rather extensive list of file systems (alas, it's
>> GPLv3+ code, so we can't use it verbatim without asking Jim Meyering and
>> other coreutils folks to relax the license):
>> http://git.sv.gnu.org/cgit/coreutils.git/tree/src/stat.c#n243
>
> Would it be worth moving the list of known file systems, and knowledge
> of whether they are remote (shared) or local, out of coreutils and into
> a gnulib module, for reuse by other projects?  Libvirt (LGPLv2+) has to
> make decisions based on what file system is hosting a guest image (guest
> migration behaves differently depending on whether the guest disk image
> resides on a local or a shared file system).  Licensing may be a
> sticking point - coreutils' list is currently GPLv3+, but is derived
> from the kernel (GPLv2), and libvirt cannot reuse it unless it is
> further relaxed to LGPLv2+.

Hi Eric,
Moving it to gnulib sounds sensible, and I'm ok with the switch to LGPLv2+.
It is currently v3 merely by virtue of residing in a .c file that calls exit.

If you do this, please consider addressing this comment:

    case S_MAGIC_AUFS: /* 0x61756673 remote */
      /* FIXME: change syntax or add an optional attribute like "inotify:no".
         The above is labeled as "remote" so that tail always uses polling,
         but this isn't really a remote file system type.  */
      return "aufs";

It is referring to the fact that while initially "local" and "remote"
were sufficient, for some file system types, the lines have blurred,
making those terms misnomers.  The intended boolean is something like
"has_inotify_support".

Also, coreutils has makefile rules that try to add new types to the
list -- typically we'd run those manually, just prior to a release.
I'd like to preserve that functionality one way or another.

Thanks,
Jim