glusterfs.git, branch v3.3.2qa2

cluster/dht: Correct min_free_disk behaviour

2013-04-17T11:53:57+00:00

Problem:
Files were being created in subvol which had less than min_free_disk available
even in the cases where other subvols with more space were available.

Solution:
Changed the logic to look for subvol which has more space available. In cases
where all the subvols have lesser than Min_free_disk available , the one with
max space and atleast one inode is available.

Known Issue: Cannot ensure that first file that is created right after
min-free-value is crossed on a brick will get created in other brick because
disk usage stat takes some time to update in glusterprocess. Will fix that as
part of another bug.

Change-Id: Icaba552db053ad8b00be0914b1f4853fb7661bd3
BUG: 874554
Signed-off-by: Raghavendra Talur 
Signed-off-by: Varun Shastry 
Reviewed-on: http://review.gluster.org/4839
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

dht: improve transform/detransform of d_off (and be ext4 safe)

2013-04-16T17:35:59+00:00

Backporting  Avati's fix http://review.gluster.org/4711

The scheme to encode brick d_off and brick id into global d_off has
two approaches. Since both brick d_off and global d_off are both 64-bit
wide, we need to be careful about how the brick id is encoded.

Filesystems like XFS always give a d_off which fits within 32bits. So
we have another 32bits (actually 31, in this scheme, as seen ahead) to
encode the brick id - which is typically plenty.

Filesystems like the recent EXT4 utilize the upto 63 low bits in d_off,
as the d_off is calculated based on a hash function value. This leaves
us no "unused" bits to encode the brick id.

However both these filesystmes (EXT4 more importantly) are "tolerant" in
terms of the accuracy of the value presented back in seekdir(). i.e, a
seekdir(val) actually seeks to the entry which has the "closest" true
offset.

This "two-prong" scheme exploits this behavior - which seems to be the
best middle ground amongst various approaches and has all the advantages
of the old approach:

- Works against XFS and EXT4, the two most common filesystems out there.
  (which wasn't an "advantage" of the old approach as it is borken against
   EXT4)

- Probably works against most of the others as well. The ones which would
  NOT work are those which return HUGE d_offs _and_ NOT tolerant to
  seekdir() to "closest" true offset.

- Nothing to "remember in memory" or evict "old entries".

- Works fine across NFS server reboots and also NFS head failover.

- Tolerant to seekdir() to arbitrary locations.

Algorithm:

Each d_off can be encoded in either of the two schemes. There is no
requirement to encode all d_offs of a directory or a reply-set in
the same scheme.

The topmost bit of the 64 bits is used to specify the "type" of encoding
of this particular d_off. If the topmost bit (bit-63) is 1, it indicates
that the encoding scheme holds a HUGE d_off. If the topmost bit is is 0,
it indicates that the "small" d_off encoding scheme is used.

The goal of the "small" d_off encoding is to stay as dense as possible
towards the lower bits even in the global d_off.

The goal of the HUGE d_off encoding is to stay as accurate (close) as
possible to the "true" d_off after a round of encoding and decoding.

If DHT has N subvolumes, we need ROOF(Log2(N)) "bits" to encode the brick
ID (call it "n").

SMALL d_off
===========

Encoding
--------
    If the top n + 1 bits are free in a brick offset, then we leave the
top bit as 0 and set the remaining bits based on the old formula:

   hi_mask = 0xffffffffffffffff

   hi_mask = ~(hi_mask >> (n + 1))

   if ((hi_mask & d_off_brick) != 0)
       do_large_d_off_encoding ()

   d_off_global = (d_off_brick * N) + brick_id

Decoding
--------
    If the top bit in the global offset is 0, it indicates that this
is the encoding formula used. So decoding such a global offset will
be like the old formula:

   if ((d_off_global & 0x8000000000000000) != 0)
      do_large_d_off_decoding()

   d_off_brick = (d_off_global % N)

   brick_id = d_off_global / N

HUGE d_off
==========

Encoding
--------
   If the top n + 1 bits are NOT free in a given brick offset, then we
set the top bit as 1 in the global offset. The low n bits are replaced
by brick_id.

    low_mask = 0xffffffffffffffff << n   // where n is ROOF(Log2(N))

    d_off_global = (0x8000000000000000 | d_off_brick & low_mask) + brick_id

    if (d_off_global == 0xffffffffffffffff)
        discard_entry();

Decoding
--------
    If the top bit in the global offset is set 1, it indicates that
the encoding formula used is above. So decoding would look like:

    hi_mask = (0xffffffffffffffff << n)
    low_mask = ~(hi_mask)

    d_off_brick = (global_d_off & hi_mask & 0x7fffffffffffffff)

    brick_id = global_d_off & low_mask

    If "losing" the low n bits in this decoding of d_off_brick looks
"scary", we need to realize that till recently EXT4 used to only
return what can now be expressed as (d_off_global >> 32). The extra
31 bits of hash added by EXT recently, only decreases the probability
of a collision, and not eliminate it completely, anyways. In a way,
the "lost" n bits are made up by decreasing the probability of
collision by sharding the files into N bricks / EXT directories
    -- call it "hash hedging", if you will :-)

Change-Id: I9551c581c3f3d4c9e719764881036d554f60c557
Thanks-to: Zach Brown 
BUG: 838784
Signed-off-by: shishir gowda 
Reviewed-on: http://review.gluster.org/4799
Reviewed-by: Amar Tumballi 
Reviewed-by: Jeff Darcy 
Tested-by: Gluster Build System 
Reviewed-on: http://review.gluster.org/4822

dict: Put "goto out" in dict_unserialize to avoid process crash

2013-04-12T07:21:09+00:00

Problem:
In the dictionary serialization function, if the
[(buf + vallen) > (orig_buf + size)], then memdup is getting failed.

Fix:
Put "goto out" whenever this condition is met.

Change-Id: Ia10ddc7e1cf551eed0e2c3d0f0364c6961e13025
BUG: 947824
Signed-off-by: Venkatesh Somyajulu 
Reviewed-on: http://review.gluster.org/4770
Tested-by: Gluster Build System 
Reviewed-by: Jeff Darcy

cluster/afr: Try for all locks before failing in rename

2013-04-10T08:26:09+00:00

Change-Id: If0e917e5d4914f6807b4a96f81668a467b15d0df
BUG: 922809
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4689
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

cluster/afr: Preserve mtime in self-heal

2013-04-10T07:41:19+00:00

Problem:
Data self-heal may choose sink iatt to set mtimes.
This happens because after syncing of data is done
self-heal does one more xattrops/fstat to determine
sources sinks to set the inode-ctx. Since this is done
after data syncing and erase of xattrs, old source and
old sink are now sources, but the mtimes of them differ.
Old code just takes the first source from the list and
update mtimes, which could be sink before the self-heal
started.

Fix:
Set mtime from 'sources before syncing'.

Change-Id: Id769e1b99aa4f041eaee775f64cbf2c57b799723
BUG: 918437
Signed-off-by: Pranith Kumar K 
Reviewed-on: http://review.gluster.org/4658
Reviewed-by: Jeff Darcy 
Tested-by: Gluster Build System 
Reviewed-on: http://review.gluster.org/4664
Reviewed-by: Vijay Bellur

Fix spelling error

2013-03-13T03:06:42+00:00

"temporary" was misspelled
s/tempaory/temporary/

BUG: 818884

Change-Id: If033acd4d8d778bde7588d8b4b512d6508e36f22
Signed-off-by: Joe Julian 
Reviewed-on: http://review.gluster.org/4661
Reviewed-by: Jeff Darcy 
Tested-by: Anand Avati

rpm: package /var/run/gluster so that statedumps can be created

2013-03-07T06:14:06+00:00

Creating statedumps fail when /var/run/gluster does not exist. This
directory should be part of the 'glusterfs' package that is installed on
storage servers and native clients.

BUG: 917554
Change-Id: I2f6d8dc46f338b33042478d19ed9f00c2c03658c
Signed-off-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/4615
Tested-by: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Shishir Gowda 
Reviewed-by: Anand Avati

libglusterfs: Fix memory leaks in fd_lk_insert_and_merge

2013-02-18T04:49:42+00:00

Change-Id: Id322717b79c5252172811fea259f2073f710a463
BUG: 834465
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/4530
Reviewed-by: Anand Avati 
Tested-by: Anand Avati

localtime and ctime are not MT-SAFE

2013-02-08T20:04:42+00:00

There are a number of nit-level issues throughout the source with
the use of localtime and ctime. While they apparently aren't causing
too many problems, apart from the one in bz 828058, they ought to be
fixed. Among the "real" problems that are fixed in this patch:
1) general localtime and ctime not MT-SAFE. There's a non-zero chance
   that another thread calling localtime (or ctime) will over-write
   the static data about to be used in another thread
2) localtime(& <64-bit-type>) or ctime(& <64-bit-type>) generally
   not a problem on 64-bit or little-endian 32-bit. But even though
   we probably have zero users on big-ending 32-bit platforms, it's
   still incorrect.
3) multiple nested calls passed as params. Last one wins, i.e. over-
   writes result of prior calls.
4) Inconsistent error handling. Most of these calls are for logging,
   tracing, or dumping. I submit that if an error somehow occurs in
   the call to localtime or ctime, the log/trace/dump still should
   still occur.
5) Appliances should all have their clocks set to UTC, and all log
   entries, traces, and dumps should use GMT.
6) fix strtok(), change to strtok_r()

Other things this patch fixes/changes (that aren't bugs per se):
1) Change "%Y-%m-%d %H:%M:%S" and similar to their equivalent shorthand,
   e.g. "%F %T"
2) change sizeof(timestr) to sizeof timestr. sizeof is an operator,
   not a function. You don't use i +(32), why use sizeof().
   (And yes, you do use parens with sizeof().)
3) change 'char timestr[256]' to 'char timestr[32]' where appropriate.
   Per-thread stack is limited. Time strings are never longer than ~20
   characters, so why waste 220+ bytes on the stack?

Things this patch doesn't fix:
1) hodgepodge of %Y-%m-%d %H:%M:%S versus %Y/%m/%d-%H%M%S and other
   variations. It's not clear to me whether this ever matters, not to
   mention 3rd party log filtering tools may already rely on a
   particular format. Still it would be nice to have a single manifest
   constant and have every call to localtime/strftime consistently use
   the same format.

BUG: 832173

Change-Id: Iee9719db4576eacc6c75694d9107954d0912cba8
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/3613
Reviewed-by: Anand Avati 
Tested-by: Anand Avati

performance/quick-read: fix race condition in unlink

2013-02-07T22:41:32+00:00

use same lock (inode->lock), while incrementing/decrementing local->open_count.

Change-Id: I08cbab5b5dec09b6057f43324fe3152f1564ce46
BUG: 902174
Signed-off-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/4396
Reviewed-by: Anand Avati 
Tested-by: Anand Avati