glusterfs.git/libglusterfs/src/inode.c, branch v3.7.19

inode: Adjust lru_size while retiring entries in lru list

2016-08-11T04:15:19+00:00

As part of inode_table_destroy(), we first retire entries
in the lru list but the lru_size is not adjusted accordingly.
This may result in invalid memory reference in inode_table_prune
if the lru_size > lru_limit.

> Reviewed-on: http://review.gluster.org/15087
> Smoke: Gluster Build System 
> CentOS-regression: Gluster Build System 
> NetBSD-regression: NetBSD Build System 
> Reviewed-by: Raghavendra G 
> Reviewed-by: Prashanth Pai 

BUG: 1365746
Change-Id: I29ee3c03b0eaa8a118d06dc0cefba85877daf963
Signed-off-by: Soumya Koduri 
Signed-off-by: Oleksandr Natalenko 
Reviewed-on: http://review.gluster.org/15128
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Prashanth Pai 
CentOS-regression: Gluster Build System

libglusterfs/gfapi: set appropriate errno for inode_link failures

2016-05-11T14:36:33+00:00

We do not seem to be setting errno appropriately in case
of inode_link failures. This errno may be used by any application
(for eg., nfs-ganesha) to determine the error encountered. This
patch addresses the same.

This is backport of below mainline fix -
        http://review.gluster.org/14278

Change-Id: I674f747c73369d0597a9c463e6ea4c85b9091355
BUG: 1335016
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/14278
Reviewed-by: Niels de Vos 
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Kaleb KEITHLEY 
Reviewed-on: http://review.gluster.org/14287
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

inode: Always fetch first entry from the inode lists during inode_table_destroy

2016-04-29T09:06:23+00:00

In inode_table_destroy, we iterate through lru and active lists
to move the entries to purge list so that they can be destroyed
during inode_table_prune.

But if used "list_for_each_entry" or "list_for_each_entry_safe"
to iterate, we could end up accessing the entries which may have
got moved to different(purge) lists in the process and can result
in either infinite loop or crash. The safe approach seems to fetch
the first entry of the list in each iteration till it gets empty.

This is backport of below mainline fix -
        http://review.gluster.org/13987

Change-Id: I24a18881833bd9419c2d8e5e8807bc71ec396479
BUG: 1330892
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13987
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Niels de Vos 
Reviewed-by: Jeff Darcy 
Reviewed-on: http://review.gluster.org/14089
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

inode: Retire the inodes from the lru list in inode_table_destroy

2016-02-28T22:17:37+00:00

Inodes from the lru list are not moved to purge list unless they
are retired. Also process the lru list first to unset their parent
as we need to unset their dentry entries (the ones which may not be
unset during '__inode_passivate' as they were hashed) which in turn
shall unref their parent inodes which could be in active list.

These parent inodes when unref'ed may well again fall into lru list
and if we are at the end of traversing the list, we may miss to
delete/retire that entry. Hence traverse the lru list till it
gets empty.

This is backport of the below patch
  - http://review.gluster.org/13125

Change-Id: Ib7666e235e9b9644144a7c7933afb5e407e506ca
BUG: 1311441
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13125
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Raghavendra G 
Reviewed-on: http://review.gluster.org/13527
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

fuse: send lookup if inode_ctx is not set

2016-02-22T14:45:32+00:00

During resolving of an entry or inode, if inode ctx
was not set, we will send a lookup.

This patch also make sure that inode_ctx will be created
after every inode_link

Back port of>
>Change-Id: I4211533ca96a51b89d9f010fc57133470e52dc11
>BUG: 1297311
>Signed-off-by: Mohammed Rafi KC 
>Reviewed-on: http://review.gluster.org/13225
>Reviewed-by: Dan Lambright 

Change-Id: I53d7f77b5b9a9e095aeeccdd3605dcce7eade0b2
BUG: 1306131
Tested-by: Dan Lambright 
Reviewed-on: http://review.gluster.org/13416
Smoke: Gluster Build System 
Tested-by: mohammed rafi  kc 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Dan Lambright

protocol/server: forget the inodes which got ENOENT in lookup

2015-08-21T11:48:48+00:00

                 Backport of http://review.gluster.org/11489

If a looked up object is removed from the backend, then upon getting a
revalidated lookup on that object ENOENT error is received. protocol/server
xlator handles it by removing dentry upon which ENOENT is received. But the
inode associated with it still remains in the inode table, and whoever does
nameless lookup on the gfid of that object will be able to do it successfully
despite the object being not present.

For handling this issue, upon getting ENOENT on a looked up entry in revalidate
lookups, protocol/server should forget the inode as well.

Though removing files directly from the backend is not allowed, in case of
objects corrupted due to bitrot and marked as bad by scrubber, objects are
removed directly from the backend in case of replicate volumes, so that the
object is healed from the good copy. For handling this, the inode of the bad
object removed from the backend should be forgotten. Otherwise, the inode which
knows the object it represents is bad, does not allow read/write operations
happening as part of self-heal.

Change-Id: I268eeaf37969458687425187be6622347a6cc1f1
BUG: 1255604
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11973
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Raghavendra G

fd,inode/libglusterfs : porting to a new logging framework

2015-07-07T12:18:35+00:00

        Backport of http://review.gluster.org/#/c/10825/

Cherry picked from d32b221747cf6742cffaff5a60e16269dffd04cc
>Change-Id: I4beba3b50456f802824374b6e3fa8079d72f2c00
>BUG: 1194640
>Signed-off-by: Mohamed Ashiq 
>Reviewed-on: http://review.gluster.org/10825
>Reviewed-by: Pranith Kumar Karampuri 
>Tested-by: Pranith Kumar Karampuri 

Change-Id: I4beba3b50456f802824374b6e3fa8079d72f2c00
BUG: 1217722
Signed-off-by: Mohamed Ashiq 
Reviewed-on: http://review.gluster.org/11402
Tested-by: Gluster Build System 
Tested-by: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

libgfapi: send explicit lookups on inodes linked in readdirp

2015-07-06T15:14:02+00:00

          Backport of http://review.gluster.org/11236

If the inode is linked via readdirp, then the consuners of gfapi which are using
handles (got either in lookup or readdirp) might not send an explicit lookup on
that object again (ex: NFS, samba, USS). If there is a replicate volume where
the replicas of the object are not in sync, then readdirp followed by fops might
lead data being served from the subvolume which is not in sync with latest
data. And since lookup is needed to trigger self-heal on that object the
consumers might keep getting wrong data until an explicit lookup is not done.

Fuse handles this situation by sending an explicit lookup by itself (fuse
xlator) on those inodes which are linked via readdirp, whenever a fop comes on
that inode.

The same procedure is done in gfapi as well to address this situation.

Thanks to shyam(srangana@redhat.com) for valuable inputs

Change-Id: I4230fae8e0b01a95c056282b08ed30832d4804a7
BUG: 1240190
Signed-off-by: Raghavendra Bhat 
Reviewed-on: http://review.gluster.org/11545
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Shyamsundar Ranganathan 
Reviewed-by: Niels de Vos

cluster/afr: Pick gfid from poststat during fresh lookup for read child calculation

2015-06-26T02:36:41+00:00

        Backport of: http://review.gluster.org/11373

Change-Id: I3ddc70cb0e7dbd1ef8adb352393b5ec16464fc94
BUG: 1212842
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/11391
Tested-by: NetBSD Build System 
Tested-by: Gluster Build System 
Reviewed-by: Pranith Kumar Karampuri

Avoid conflict between contrib/uuid and system uuid

2015-04-04T17:48:35+00:00

glusterfs relies on Linux uuid implementation, which
API is incompatible with most other systems's uuid. As
a result, libglusterfs has to embed contrib/uuid,
which is the Linux implementation, on non Linux systems.
This implementation is incompatible with systtem's
built in, but the symbols have the same names.

Usually this is not a problem because when we link
with -lglusterfs, libc's symbols are trumped. However
there is a problem when a program not linked with
-lglusterfs will dlopen() glusterfs component. In
such a case, libc's uuid implementation is already
loaded in the calling program, and it will be used
instead of libglusterfs's implementation, causing
crashes.

A possible workaround is to use pre-load libglusterfs
in the calling program (using LD_PRELOAD on NetBSD for
instance), but such a mechanism is not portable, nor
is it flexible. A much better approach is to rename
libglusterfs's uuid_* functions to gf_uuid_* to avoid
any possible conflict. This is what this change attempts.

BUG: 1206587
Change-Id: I9ccd3e13afed1c7fc18508e92c7beb0f5d49f31a
Signed-off-by: Emmanuel Dreyfus 
Reviewed-on: http://review.gluster.org/10017
Tested-by: Gluster Build System 
Reviewed-by: Niels de Vos