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