[libvirt] [PATCHv2 3/3] storage: implement rudimentary glusterfs pool refresh
Eric Blake
eblake at redhat.com
Mon Nov 4 18:28:31 UTC 2013
On 11/04/2013 11:02 AM, Peter Krempa wrote:
>> +
>> + /* 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,
Hmm, that's news to me - when I first set up gluster on my machine, the
docs I read seemed to state that formatting my brick as XFS was
mandatory. It's actually nicer if gluster supports bricks of different
types, but that may have impact on NAME_MAX - I guess it's time to ask
upstream.
>
>> + * 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.
If you can get gluster to support a filename longer than 255 bytes (256
includes the trailing NUL), then there's upstream bugs in gluster that
need resolving first. That is, I suspect that even if gluster can wrap
a Reiser 4 file system brick, that gluster itself still needs to stick
to a 255 limit. But that implies that I need to update the text of my
comment (as it is not just XFS at play).
>
>> + * 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
>
>
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131104/f7ac03ce/attachment-0001.sig>
More information about the libvir-list
mailing list