REVIEW: http://review.gluster.org/10436 (cluster/ec: Handle unhandled states) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

REVIEW: http://review.gluster.org/10437 (storage/posix: prevent NULL dereference) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

REVIEW: http://review.gluster.org/10438 (syncop: Implement syncop_fxattrop) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

REVIEW: http://review.gluster.org/10439 (libglusterfs: Implement cluster-syncop) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

REVIEW: http://review.gluster.org/10440 (cluster/ec: Perform inode-write on healing subvols) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

COMMIT: http://review.gluster.org/10436 committed in release-3.7 by Vijay Bellur (vbellur) 
------
commit 4603b3efc2c10519b22dd486211fd5cc7f0de0b0
Author: Pranith Kumar K <pkarampu>
Date:   Mon Apr 27 00:00:08 2015 +0530

    cluster/ec: Handle unhandled states
    
            Backport of http://review.gluster.org/10390
    
    This was leading to hangs when get_size_and_version fails
    
    BUG: 1216303
    Change-Id: Iae455ee957b9377e1b0b711b0ef567d50d32c7cb
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10436
    Tested-by: NetBSD Build System
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

COMMIT: http://review.gluster.org/10437 committed in release-3.7 by Vijay Bellur (vbellur) 
------
commit b8a5d23ac69c686242262bff43583d3871fff2c0
Author: Pranith Kumar K <pkarampu>
Date:   Sun Apr 26 17:59:49 2015 +0530

    storage/posix: prevent NULL dereference
    
            Backport of http://review.gluster.org/10383
    
    filler->fd is never set but used.
    
    BUG: 1216303
    Change-Id: I02dc346c526be5af4ea55ae13e8314316f127455
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10437
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: NetBSD Build System
    Reviewed-by: Vijay Bellur <vbellur>

REVIEW: http://review.gluster.org/10438 (syncop: Implement syncop_fxattrop) posted (#2) for review on release-3.7 by Vijay Bellur (vbellur)

REVIEW: http://review.gluster.org/10439 (libglusterfs: Implement cluster-syncop) posted (#2) for review on release-3.7 by Vijay Bellur (vbellur)

REVIEW: http://review.gluster.org/10440 (cluster/ec: Perform inode-write on healing subvols) posted (#2) for review on release-3.7 by Vijay Bellur (vbellur)

COMMIT: http://review.gluster.org/10438 committed in release-3.7 by Vijay Bellur (vbellur) 
------
commit 6562656f69dae5a7c9251ae86e12a1a45dbfd7f9
Author: Pranith Kumar K <pkarampu>
Date:   Sun Apr 26 10:40:18 2015 +0530

    syncop: Implement syncop_fxattrop
    
            Backport of http://review.gluster.org/10382
    
    BUG: 1216303
    Change-Id: I4433002906efc6894b4ff8de8fefe8b7bc954dcf
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10438
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Vijay Bellur <vbellur>

REVIEW: http://review.gluster.org/10440 (cluster/ec: Perform inode-write on healing subvols) posted (#3) for review on release-3.7 by Vijay Bellur (vbellur)

COMMIT: http://review.gluster.org/10440 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) 
------
commit 3994afd6140c828edceca271974f5a90c4c70fad
Author: Pranith Kumar K <pkarampu>
Date:   Thu Apr 23 08:30:11 2015 +0530

    cluster/ec: Perform inode-write on healing subvols
    
            Backport of http://review.gluster.org/10372
    
    If the version numbers do not match, then writes are performed only on at least
    N-R bricks which have same version. But if we want to do healing of files which
    are constantly modified we need to allow writes on subvols that are undergoing
    heal. Data healing will mark 62nd bit while the heal is going on. When the data
    transaction sees that this bit is set it needs to perform the fop on that
    subvol irrespective of whether the versions match or do not match. Fop is
    considered successful only if N-R non-healing bricks succeed.
    
    BUG: 1216303
    Change-Id: I79aaf1ac86357c51547cdaaa56cf7338004cc512
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10440
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: NetBSD Build System

REVIEW: http://review.gluster.org/10690 (cluster/ec: Fix dictionary compare function) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

REVIEW: http://review.gluster.org/10691 (cluster/ec: metadata/name/entry heal implementation for ec) posted (#1) for review on release-3.7 by Pranith Kumar Karampuri (pkarampu)

COMMIT: http://review.gluster.org/10690 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) 
------
commit e0401209cf58a638a32e7d867ab4c6199aa0e92f
Author: Pranith Kumar K <pkarampu>
Date:   Tue Mar 31 23:07:09 2015 +0530

    cluster/ec: Fix dictionary compare function
    
    If both dicts are NULL then equal. If one of the dicts is NULL but the other
    has only ignorable keys then also they are equal. If both dicts are non-null
    then check if for each non-ignorable key, values are same or not.  value_ignore
    function is used to skip comparing values for the keys which must be present in
    both the dictionaries but the value could be different.
    
    geo-rep's stime xattr doesn't need to be present in list xattr but when
    getxattr comes on stime xattr even if there aren't enough responses with the
    xattr we should still give out an answer which is maximum of the stimes
    available.
    
    Change-Id: I8de2ceaa2db785b797f302f585d88e73b154167d
    BUG: 1216303
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10078
    Reviewed-on: http://review.gluster.org/10690
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: NetBSD Build System

COMMIT: http://review.gluster.org/10691 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) 
------
commit fae1e70ff3309d2b64febaafc70abcaa2771ecf0
Author: Pranith Kumar K <pkarampu>
Date:   Thu Apr 16 09:25:31 2015 +0530

    cluster/ec: metadata/name/entry heal implementation for ec
    
    Metadata self-heal:
    1) Take inode lock in domain 'this->name' on 0-0 range (full file)
    2) perform lookup and get the xattrs on all the bricks
    3) Choose the brick with highest version as source
    4) Setattr uid/gid/permissions
    5) removexattr stale xattrs
    6) Setxattr existing/new xattrs
    7) xattrop with -ve values of 'dirty' and difference of highest and its own
       version values for version xattr
    8) unlock lock acquired in 1)
    
    Entry self-heal:
    1) take directory lock in domain 'this->name:self-heal' on 'NULL' to prevent
       more than one self-heal
    2) we take directory lock in domain 'this->name' on 'NULL'
    3) Perform lookup on version, dirty and remember the values
    4) unlock lock acquired in 2)
    5) readdir on all the bricks and trigger name heals
    6) xattrop with -ve values of 'dirty' and difference of highest and its own
       version values for version xattr
    7) unlock lock acquired in 1)
    
    Name heal:
    1) Take 'name' lock in 'this->name' on 'NULL'
    2) Perform lookup on 'name' and get stat and xattr structures
    3) Build gfid_db where for each gfid we know what subvolumes/bricks have
       a file with 'name'
    4) Delete all the stale files i.e. the file does not exist on more than
       ec->redundancy number of bricks
    5) On all the subvolumes/bricks with missing entry create 'name' with same
       type,gfid,permissions etc.
    6) Unlock lock acquired in 1)
    Known limitation: At the moment with present design, it conservatively
    preserves the 'name' in case it can not decide whether to delete it.  this can
    happen in the following scenario:
    1) we have 3=2+1 (bricks: A, B, C) ec volume and 1 brick is down (Lets say A)
    2) rename d1/f1 -> d2/f2 is performed but the rename is successful only on one
       of the bricks (Lets say B)
    3) Now name self-heal on d1 and d2 would re-create the file on both d1 and d2
       resulting in d1/f1 and d2/f2.
    
    Because we wanted to prevent data loss in the case above, the following
    scenario is not healable, i.e. it needs manual intervention:
    1) we have 3=2+1 (bricks: A, B, C) ec volume and 1 brick is down (Lets say A)
    2) We have two hard links: d1/a, d2/b and another file d3/c even before the
       brick went down
    3) rename d3/c -> d2/b is performed
    4) Now name self-heal on d2/b doesn't heal because d2/b with older gfid will
       not be deleted.  One could think why not delete the link if there is
       more than 1 hardlink, but that leads to similar data loss issue I described
       earlier:
    Scenario:
    1) we have 3=2+1 (bricks: A, B, C) ec volume and 1 brick is down (Lets say A)
    2) We have two hard links: d1/a, d2/b
    3) rename d1/a -> d3/c, d2/b -> d4/d is performed and both the operations are
       successful only on one of the bricks (Lets say B)
    4) Now name self-heal on the 'names' above which can happen in parallel can
       decide to delete the file thinking it has 2 links but after all the
       self-heals do unlinks we are left with data loss.
    
    Change-Id: I3a68218a47bb726bd684604efea63cf11cfd11be
    BUG: 1216303
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10298
    Reviewed-on: http://review.gluster.org/10691
    Tested-by: Gluster Build System <jenkins.com>
    Tested-by: NetBSD Build System

COMMIT: http://review.gluster.org/10692 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) 
------
commit f54b232b3cc61ee9ca76288958537b53de64de53
Author: Pranith Kumar K <pkarampu>
Date:   Sat Apr 25 15:58:09 2015 +0530

    cluster/ec: data heal implementation for ec
    
    Data self-heal:
    1) Take inode lock in domain 'this->name:self-heal' on 0-0 range (full file),
       So that no other processes try to do self-heal at the same time.
    2) Take inode lock in domain 'this->name' on 0-0 range (full file),
    3) perform fxattrop+fstat and get the xattrs on all the bricks
    3) Choose the brick with ec->fragment number of same version as source
    4) Truncate sinks
    5) Unlock lock taken in 2)
    5) For each block take full file lock, Read from sources write to the sinks, Unlock
    6) Take full file lock and see if the file is still sane copy i.e. File didn't become unusable while the bricks are offline.
       Update mtime to before healing
    7) xattrop with -ve values of 'dirty' and difference of highest and its own
       version values for version xattr
    8) unlock lock acquired in 6)
    9) unlock lock acquired in 1)
    
    Change-Id: I6f4d42cd5423c767262c9d7bb5ca7767adb3e5fd
    BUG: 1216303
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10384
    Reviewed-on: http://review.gluster.org/10692
    Tested-by: Gluster Build System <jenkins.com>

COMMIT: http://review.gluster.org/10693 committed in release-3.7 by Pranith Kumar Karampuri (pkarampu) 
------
commit a327b9fa9d50a66e7bb3a887ac569be914132d10
Author: Pranith Kumar K <pkarampu>
Date:   Sun Apr 26 14:28:00 2015 +0530

    cluster/ec: Change meaning of trusted.ec.dirty
    
    - With this change, the xattr will represent if the file needs to be healed or
      not. It will have different values for data/entry and metadata changes.
    - inode ref leaks and dict_set_dynstr related leaks fixed
    - Added support for trylock/lock based on heal-cmd execution or not
      in data heal.
    - Made fixes to pass regression runs
    
    Change-Id: I9d8def4c2badde18a76b7898816fecfac113737a
    BUG: 1216303
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/10385
    Reviewed-on: http://review.gluster.org/10693
    Tested-by: NetBSD Build System
    Tested-by: Gluster Build System <jenkins.com>

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.0, please open a new bug report.

glusterfs-3.7.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://thread.gmane.org/gmane.comp.file-systems.gluster.devel/10939
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user