Signed-off-by: Raghavendra G <raghavendra@gluster.com>
Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 369 (Samba does not work with booster.)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=369

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

When an fd_t is fd_create'd, we need to call fd_bind on it to
ensure that any fd_lookup on the inode gets us this fd. We're not
doing this so translators like write-behind were not able to order
path-based requests at all resulting in some fops like stat, which
could be issued after a writev, overtaking a previous writev which
is still being written-behind.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 179 (fileop reports miscompares on read tests)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=179

Till now we've been creating an iovec, storing references in it
to the application data and simply passing it on to the translator
tree. This means that the buffer being passed to the translators is
not at all associated with the memory ref'd by the iobref argument
to write fop. This is a problem when write-behind is a translator in
the tree since it assumes that the memory in the iovecs passed to
write fops is already refcounted by the iobref and so it simply copies
the address of the application data. The problem is that the application
can continue using this buffer, free it or over-write it destroying the
data that write-behind may write at a later time.

The solution involves copying the application's write buffer into
an iobuf which will be referred to by the iobref.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 178 (libglusterfsclient: Data corruption on using write-behind in translator tree)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=178

This is needed to work around the replicate behaviour of
possibly returning device number for the same file from

different subvolumes.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 148 (replicate: Returns st_dev from different subvols resulting in ESTALE thru unfs3booster)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=148

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

BUG: 149 (libglusterfsclient interacts incorrectly with write-behind on writev)
URL: http://bugs.gluster.com/cgi-bin/bugzilla3/show_bug.cgi?id=149

We werent updating the attr AKA stat cache on read and write
on files so every stat on the file before the timeout was returning
stale attr from the cache. Yuck!

This fixes it. Turns out there is a good aspect of unfs3's notoriety
when it comes to doing stat()s for every operation.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

- this helps in implementing sendfile(2). manpage says that
    "If offset is  not  NULL,  then sendfile()  does  not modify the current
     file offset of in_fd"

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

We can avoid memory allocation, de-allocation and
data copies by just using the entries passed to us from
a lower layer and by de-linking the entries from the original
list.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>

The fop interface is such that we're able to extract more than
1 dirent in a readdir fop. This commit now enables libglusterfsclient
to read multiple entries on a glusterfs_readdir call. Once these
have been pre-fetched, they're cached till either glusterfs_closedir
,glusterfs_rewinddir or glusterfs_seekdir are called.
The current implementation is beneficial for sequential directory
reading and probably indifferent to applications that do a lot of seekdir
and rewinddir after opening the directory. This is because
both these calls result in dirent cache invalidation.

Signed-off-by: Anand V. Avati <avati@dev.gluster.com>