Re: [PATCHv2 3/3] storage: implement rudimentary glusterfs pool refresh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]