[libvirt] [PATCHv2 3/3] storage: implement rudimentary glusterfs pool refresh

[Peter Krempa]

On 11/04/13 18:03, Eric Blake wrote:
> Actually put gfapi to use, by allowing the creation of a gluster
> pool.  Right now, all volumes are treated as raw; further patches
> will allow peering into files to allow for qcow2 files and backing
> chains, and reporting proper volume allocation.
> 
> I've reported a couple of glusterfs bugs; if we were to require a
> minimum of (not-yet-released) glusterfs 3.5, we could use the new
> glfs_readdir [1] and not worry about the bogus return value of
> glfs_fini [2], but for now I'm testing with Fedora 19's glusterfs
> 3.4.1.
> 
> [1] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00085.html
> [2] http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00086.html
> 
> * src/storage/storage_backend_gluster.c
> (virStorageBackendGlusterRefreshPool): Initial implementation.
> (virStorageBackendGlusterOpen, virStorageBackendGlusterClose): New
> helper functions.
> 
> Signed-off-by: Eric Blake <eblake at redhat.com>
> ---
>  src/storage/storage_backend_gluster.c | 192 +++++++++++++++++++++++++++++++++-
>  1 file changed, 187 insertions(+), 5 deletions(-)
> 

...

> +
> +    /* Why oh why did glfs 3.4 decide to expose only readdir_r rather
> +     * than readdir?  POSIX admits that readdir_r is inherently a
> +     * flawed design, because systems are not required to define
> +     * NAME_MAX: http://austingroupbugs.net/view.php?id=696
> +     * http://womble.decadent.org.uk/readdir_r-advisory.html
> +     *
> +     * Fortunately, gluster uses _only_ XFS file systems, and XFS has

"XFS file systems" as a group of filesystems based on XFS? Or just the
one XFS file systems. In case of the latter the statement wouldn't be
true. I deployed gluster on ext4 and it works happily. In fact any posix
compatible filesystem seems to work well with gluster,

> +     * a known NAME_MAX of 255; so we are guaranteed that if we
> +     * provide 256 bytes of tail padding, then we have enough space to

Anyhow, the 256 bytes limit is good enough for most of the filesystems
according to
http://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits

Tomorrow I'll try deploying Reiser 4, which seems to support 4096 byte
file names. If it will work happily with gluster we will need to
reconsider this limit.

> +     * avoid buffer overflow no matter whether the OS used d_name[],
> +     * d_name[1], or d_name[256] in its 'struct dirent'.
> +     * http://lists.gnu.org/archive/html/gluster-devel/2013-10/msg00083.html
> +     */
> +

I'll do a proper review of this patch tomorrow.

Peter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131104/83711be1/attachment-0001.sig>