[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] util: recognize SMB filesystems as shared

On 09/26/2013 03:33 PM, Eric Blake 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+.

I'd be happy moving that list to an LGPLv2+ gnulib module

For reference, from my coreutils build here:

$ grep "return 0" src/fs-is-local.h
      case S_MAGIC_AFS: return 0;
      case S_MAGIC_AUFS: return 0;
      case S_MAGIC_CEPH: return 0;
      case S_MAGIC_CIFS: return 0;
      case S_MAGIC_CODA: return 0;
      case S_MAGIC_FHGFS: return 0;
      case S_MAGIC_FUSEBLK: return 0;
      case S_MAGIC_FUSECTL: return 0;
      case S_MAGIC_GFS: return 0;
      case S_MAGIC_GPFS: return 0;
      case S_MAGIC_KAFS: return 0;
      case S_MAGIC_LUSTRE: return 0;
      case S_MAGIC_NCP: return 0;
      case S_MAGIC_NFS: return 0;
      case S_MAGIC_NFSD: return 0;
      case S_MAGIC_OCFS2: return 0;
      case S_MAGIC_PANFS: return 0;
      case S_MAGIC_PIPEFS: return 0;
      case S_MAGIC_SMB: return 0;
      case S_MAGIC_SNFS: return 0;
      case S_MAGIC_VMHGFS: return 0;

I would be better of course if there was some
introspection provided by the kernel.

Also we use the above to determine if "remote" or not.
Whether those remote file ssytems are used in a shared
context is another question I suppose.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]