| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Intro Note
==========
The current code in hard fh resolution takes the first-match approach, i.e.
which ever dirent either matches the hash or matches the gfid first
is the one chosen as the result for the next step of fh resolution. In
the latter case, i.e., dirent matches the gfid, we the next step is to
conclude the fh resolution by returning the entry whose gfid matched.
In the former, i.e., the hash matches the dirent, we choose the hash-matching
dirent as the next directory to descend into, for searching the file to be
operated upon.
Problem
=======
When performing hard fh resolution, there can be a situation where:
o the hash of the primary entry,i.e. the entry we're looking for and the hash
of another sibling directory, match. Note the use of "sibling", meaning both
the primary entry and the hash matching one are in the same directory, i.e.,
their filehandle.hashcount will be same.
o the sibling directory is encountered first during the dir search.
Because of the current code described in "Intro", we'll end up descending into
the sibling directory even though the correct behaviour is to ignore this and
wait till we encounter the primary entry in the same parent directory.
Once we end up descending into this sibling directory, the directory depth
validation check fails. The check fails because it notices that the resolution
is attempting to open a directory that is deeper in the fs tree than the file
we're looking for. When this check fails, we return an ESTALE. So basically, a
false-positive results in an estale to Specsfs.
This is not a theoretical situation. Me and Avati saw this on specsfs test
where sfs created terabytes-sized file system for its tests. The number of
files was so huge in a single directory that the hashes of two entries ended up
colliding.
Change-Id: I78d8756252330201e165d788a29277b4bce0df90
BUG: 3510
Reviewed-on: http://review.gluster.com/358
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Shehjar Tikoo <shehjart@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Id1f1a91cf15d933d5621a0073ddaebe02df0f159
BUG: 3348
Reviewed-on: http://review.gluster.com/198
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Ibf5f45431d7a55b70d7304649af652d6f25bb688
BUG: 3348
Reviewed-on: http://review.gluster.com/183
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Anand Avati <avati@gluster.com>
|
|
|
|
|
|
|
|
| |
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 2200 (cp dies with "Invalid argument" after failover)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=2200
|
|
|
|
|
|
|
|
| |
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 1756 (NFS must revalidate inode on first ESTALE on lookup)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Brings in changes that were earlier introduced in commit:
f5afcc47f9f00472d6c2b3f48127e02332cd457a
but reverted because the patch was buggy and caused a seg-fault
due to extra inode_unrefs.
It fixes that extra inode_unref and cleans up the revalidation logic.
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 1756 (NFS must revalidate inode on first ESTALE on lookup)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit be5c02a81c19336a6b922b1e1f28293c90955e7f.
By default, continue to register the three original port numbers
so that an upgrade to future version from 3.1 release does not
break mount requests against portmap, which may have old port
numbers registered.
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 1743 (XenServer is not compatible with GlusterNFS)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1743
|
|
|
|
|
|
|
|
| |
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 1743 (XenServer is not compatible with GlusterNFS)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1743
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f5afcc47f9f00472d6c2b3f48127e02332cd457a.
Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com>
Signed-off-by: Vijay Bellur <vijay@dev.gluster.com>
BUG: 1756 (NFS must revalidate inode on first ESTALE on lookup)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1756
|
|
|
|
| |
This reverts commit 6dd3b7fa3bc7acf9281cc17f08010675e2297089.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f5afcc47f9f00472d6c2b3f48127e02332cd457a.
Signed-off-by: Anand V. Avati <avati@blackhole.gluster.com>
Signed-off-by: Vijay Bellur <vijay@dev.gluster.com>
BUG: 1756 (NFS must revalidate inode on first ESTALE on lookup)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1756
|
|
|
|
|
|
|
|
| |
Signed-off-by: Pranith Kumar K <pranithk@gluster.com>
Signed-off-by: Vijay Bellur <vijay@dev.gluster.com>
BUG: 1388 ()
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1388
|
|
|
|
|
|
|
|
| |
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Vijay Bellur <vijay@dev.gluster.com>
BUG: 1756 (NFS must revalidate inode on first ESTALE on lookup)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1756
|
|
|
|
|
|
|
|
| |
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Vijay Bellur <vijay@dev.gluster.com>
BUG: 971 (dynamic volume management)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=971
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The order of locking while performing async fd opens was resulting in
a deadlock when a particular pattern of operations was generated by
compilebench. This patch improves handling of those situations while
locking the fd-cache, inode and inode queue.
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 1047 (Compilebench hangs nfs server)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=1047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduces two new options:
1. nfs3.*.trusted-write: Forces UNSTABLE writes to return STABLE to NFS
clients to prevent the clients from sending a COMMIT. STABLE writes
are still handled in a sync manner and so are COMMITs if they're sent
at all.
2. nfs3.*.trusted-sync: Forces all WRITEs and COMMITs to return STABLE
return flags to NFS clients to avoid the overhead of STABLE writes, and
COMMITs that follow UNSTABLE writes. This includes the trusted-write
functionality. In addition to the trusted-write, it also writes
STABLE writes in an UNSTABLE manner.
Both violate the NFS protocol but allow better write perf in most
configurations. Use with caution.
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 924 (Slow NFS synchronous writes)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change avoids having the nfs translator depend on the sanity
of the rpcsvc_request_t type after NFS reply has been sent. This
was a problem because the request structure is guaranteed to be
invalid after the reply for the request has been submitted by the
RPC program. NFS3 handler was ignoring this behaviour and accessing
the private in request after reply submission resulting in access to
corrupted data.
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 757 ([NFS-Alpha] Crash in nfs3_call_state_wipe)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=757
|
|
Signed-off-by: Shehjar Tikoo <shehjart@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>
BUG: 399 (NFS translator with Mount v3 and NFS v3 support)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=399
|