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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list