glusterfs.git/xlators/features, branch v3.6.0beta1

Do not assume sizeof(size_t)

2014-09-18T18:06:53+00:00

This fixes an assumption that sizeof(size_t) == sizeof(uint64_t), which
is not guaranteed. At least on NetBSD/i386, size_t is 32 bit long.

Caught by tests/basics/file-snapshot.t

This is a backport of Ib7620a2ffe8758521886af37bc280101a040d860

BUG: 1138897
Change-Id: Ie0b80ee9ddbcccaf9fd4f5d28d80fcd080b0ed40
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/8631
Tested-by: Gluster Build System 
Reviewed-by: Humble Devassy Chirammal 
Reviewed-by: Vijay Bellur

snapview-server: get the handle if its absent before doing any fop

2014-09-18T18:02:31+00:00

* Now that NFS server does inode linking in readdirp, it can resolve the
  gfid (i.e. find the right inode from its inode table) present in the
  filehandle sent by the NFS client on which a fop came. So instead of
  sending the lookup on that entry, it directly sends the fop. But
  snapview-server does not get the handle for the entries in readdirp
  (because doing a lookup on each entry via gfapi would be costly. So it
   waits till a lookup is done on that inode, to get the handle and the
   fs instance and fill it in the inode context). So when NFS resoves the
   gfid and directly sends the fop, snapview-server will not be able to
   perform the fop as the inode contet would not contain the fs instance
   and the handle. So fops should check for the handle before doing gfapi
   calls. If the handle and fs instance are not present in the inode context
   they should get them by doing an explicit lookup on the entry.

rebase of the patch http://review.gluster.org/#/c/8324/

Change-Id: I70c9c8edb2e7ddad79cf6ade3e041b9d02241cd1
BUG: 1143961
Reviewed-on: http://review.gluster.org/8768
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

snapview-server: register a callback with glusterd to get

2014-09-18T17:59:30+00:00

 notifications

* As of now snapview-server is polling (sending rpc requests to glusterd) to
  get the latest list of snapshots at some regular time intervals
  (non configurable). Instead of that register a callback with glusterd so that
  glusterd sends notifications to snapd whenever a snapshot is created/deleted
  and snapview-server can configure itself.

rebase of the patch http://review.gluster.org/#/c/8150/

Change-Id: Iee2582b1a823d50c79233a41cf2106f458b40691
BUG: 1143961
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/8767
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

USS: initialize a list before using it.

2014-09-18T17:54:30+00:00

backport of the patch http://review.gluster.org/8569 by
Raghavendra G 

Change-Id: I7b25fdf27c6d7ff66d24925bc73d9c6681259d37
BUG: 1143961
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/8764
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur

features/quota: fixes to dentry management code in rename.

2014-09-17T04:25:37+00:00

1. After a successful rename (src, dst), the dentry
  would be associated with src-inode.

2. Its src inode that survives if both of src and dst are present.

The fixes are done based on the above two observation.

Change-Id: I7492a512e3732b1455c243b02fae12d489532bfb
BUG: 1142411
Signed-off-by: Raghavendra G 
Reviewed-on-master: http://review.gluster.org/8687
Reviewed-by: susant palai 
Reviewed-by: Shyamsundar Ranganathan 
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8752

features/changelog: Removal of redundant fop color count while draining.

2014-09-09T08:09:52+00:00

BUG: 1138952
Change-Id: I594be0d09c6af2e4a34da3e819d1ab6fd85e34c4
Signed-off-by: Ajeet Jha 
Reviewed-on: http://review.gluster.org/8542
Reviewed-by: Vijay Bellur 
Tested-by: Gluster Build System 
Reviewed-on: http://review.gluster.org/8647

features/changelog: barrier all entry creation fops

2014-09-09T08:09:38+00:00

when a snapshot is taken, there are chances of entry creation fops
not being recorded either in changelog or through the recursive
ancestry xtime updation by marker. This causes consumers of changelog
(primarily geo-replication as of today) to not be aware of these entries
after a snapshot is restored. This can lead to inconsistencies. This patch
is an interim workaround to barrier creates till changelog becomes completely
crash consistent.

BUG: 1138952
Change-Id: Idd5e690a05fe2c7c5d32d1541a0d9b5132881ea7
Signed-off-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8517
Tested-by: Gluster Build System 
Reviewed-by: ajeet jha 
Reviewed-by: Aravinda VK 
Reviewed-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/8646

feature/geo-rep: Keep marker.tstamp's mtime unchangeable during snapshot.

2014-09-08T19:02:19+00:00

Problem:

Geo-replicatoin does a full xsync crawl after snapshot
restoration of slave and master. It does not do history crawl.

Analysis:

Marker creates 'marker.tstamp' file when geo-rep is started
for the first time. The virtual extended attribute
'trusted.glusterfs.volume-mark' is maintained and whenever
it is queried on gluster mount point, marker fills it on
the fly and returns the combination of uuid, ctime of
marker.tstamp and others. So ctime of marker.tstamp, in other
sense 'volume-mark'  marks the geo-rep start time when the
session is freshly created.

From the above, after the first filesystem crawl(xsync) is
done during first geo-rep start, stime should always be less
than 'volume-mark'. So whenever stime is less than volume-mark,
it does full filesystem crawl (xsync).

Root Cause:

When snapshot is restored, marker.tstamp file is freshly
created losing the timestamps, it was originally created with.

Solution:

1. Change is made to depend on mtime instead of ctime.
2. mtime and atime of marker.tstamp is restored back when
   snapshot is created and restored.

BUG: 1138952
Change-Id: I0e19e1cb2593171b9a2b41d0d303330feb7fd2b3
Signed-off-by: Kotresh H R 
Reviewed-on: http://review.gluster.org/8401
Tested-by: Gluster Build System 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8642

geo-rep/libgfchangelog: Support of symlinks while creation of working dir.

2014-09-08T17:42:39+00:00

In gf_changelog_register, enable symlink support while creating
working directory if its not already created.

BUG: 1138952
Change-Id: I8fec52a5768fae46ce30a2331f30f1d8d5e2e173
Signed-off-by: Kotresh H R 
Reviewed-on: http://review.gluster.org/8409
Reviewed-by: Venky Shankar 
Tested-by: Gluster Build System 
Tested-by: Venky Shankar 
Reviewed-on: http://review.gluster.org/8641
Reviewed-by: Vijay Bellur

geo-rep/libgfchangelog: Create working dir during changelog_register if not present.

2014-09-08T17:42:25+00:00

Earlier, xysnc's register was being called first,
which was creating working directory before calling
changelog_register. Now it is history crawl first.
Hence working directory would not have been created.
Create it in gf_changelog_register itself if it is
not already created.

BUG: 1138952
Change-Id: Ie39b9fd8c1ef7385f76a9b67d0acc3c1c2fd2bb2
Signed-off-by: Kotresh H R 
Reviewed-on: http://review.gluster.org/8399
Tested-by: Gluster Build System 
Reviewed-by: Aravinda VK 
Reviewed-by: Vijay Bellur 
Reviewed-on: http://review.gluster.org/8640