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