[Bugs] [Bug 1138897] NetBSD port

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1138897



--- Comment #41 from Anand Avati <aavati at redhat.com> ---
COMMIT: http://review.gluster.org/8864 committed in release-3.6 by Vijay Bellur
(vbellur at redhat.com) 
------
commit 5ee6a5384ee298314e1ef50c293ad5cbc281c609
Author: Emmanuel Dreyfus <manu at netbsd.org>
Date:   Thu Oct 2 02:58:50 2014 +0200

    POSIX filesystem compliance: PATH_MAX

    POSIX mandates the filesystem to support paths of lengths up to
    _XOPEN_PATH_MAX (1024).  This is the PATH_MAX limit here:
    http://pubs.opengroup.org/onlinepubs/009604499/basedefs/limits.h.html

    When using a path of 1023 bytes, the posix xlator attempts to create
    an absolute path by  prefixing the 1023 bytes path by the brick
    base path. The result is an absolute path of more than _XOPEN_PATH_MAX
    bytes which may be rejected by the backend filesystem.

    Linux's ext3fs PATH_MAX seems to defaut to 4096, which means it
    will work (except if brick base path is longer than 2072 bytes but
    it is unlikely to happen. NetBSD's FFS PATH_MAX defaults to 1024,
    which means the bug can happen regardless of brick base path length.

    If this condition is detected for a brick, the proposed fix is to
    chdir() the brick glusterfsd daemon to its brick base directory.
    Then when encountering a path that will exceed _XOPEN_PATH_MAX once
    prefixed by the brick base path, a relative path is used instead
    of an absolute one. We do not always use relative path because some
    operations require an absolute path on the brick base path itself
    (e.g.: statvfs).

    At least on NetBSD, this chdir() uncovers a race condition which
    causes file lookup to fail with ENODATA for a few seconds. The
    volume quickly reaches a sane state, but regression tests are fast
    enough to choke on it. The reason is obscure (as often with race
    conditions), but sleeping one second after the chdir() seems to
    change scheduling enough that the problem disapear.

    Note that since the chdir() is done if brick backend filesystem
    does not support path long enough, it will not occur with Linux
    ext3fs (except if brick base path is over 2072 bytes long).

    This is a backport of I7db3567948bc8fa8d99ca5f5ba6647fe425186a9

    BUG: 1138897
    Change-Id: Ib8eb3efaac8a7ba505d830623921338689229e9a
    Signed-off-by: Emmanuel Dreyfus <manu at netbsd.org>
    Reviewed-on: http://review.gluster.org/8864
    Tested-by: Gluster Build System <jenkins at build.gluster.com>
    Reviewed-by: Harshavardhana <harsha at harshavardhana.net>
    Tested-by: Harshavardhana <harsha at harshavardhana.net>
    Reviewed-by: Vijay Bellur <vbellur at redhat.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UutSwNYGpt&a=cc_unsubscribe