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