Since all of epoll code and its multithreading is under ifdefs, netbsd
should just continue working as single threaded poll unaffected by the
patch. If netbsd kqueue supports single shot event delivery and edge
triggered notification, we could have an equivalent implantation on netbsd
too. Even if
Couple of comments -
1. rdma can register init/fini functions (via pointers) into iobuf_pool.
Absolutely no need to introduce rdma dependency into libglusterfs.
2. It might be a good idea to take a holistic approach towards zero-copy
with libgfapi + RDMA, rather than a narrow goal of use
I don't think the problem is with the handling of SETATTR in either NetBSD
or Linux. I am guessing NetBSD FUSE is _using_ SETATTR to update atime upon
open? Linux FUSE just leaves it to the backend filesystem to update atime.
Whenever there is a SETATTR fop, ctime is _always_ bumped.
Thanks
On
On Tue Jan 13 2015 at 11:57:53 PM Mohammed Rafi K C rkavu...@redhat.com
wrote:
On 01/14/2015 12:11 AM, Anand Avati wrote:
3) Why not have a separate iobuf pool for RDMA?
Since every fops are using the default iobuf_pool, if we go with another
iobuf_pool dedicated to rdma, we need to copy
3) Why not have a separate iobuf pool for RDMA?
On Tue Jan 13 2015 at 6:30:09 AM Mohammed Rafi K C rkavu...@redhat.com
wrote:
Hi All,
When using RDMA protocol, we need to register the buffer which is going
to send through rdma with rdma device. In fact, it is a costly
operation, and a
Valid questions. access-control had to be as close to posix as possible in
its first implementation (to minimize the cost of the STAT calls originated
by it), but since the introduction of posix-acl there are no extra STAT
calls, and given the later introduction of quota, it certainly makes sense
Note that the mandatory locks available in the locks translator is just the
mandatory extensions for posix locks - at least one of the apps must be
using locks to begin with. What Harmeet is asking for is something
different - automatic exclusive access to edit files. i.e, if one app has
opened a
Or use an rsync style .filename.rand tempfile, write the new version of the
file, and rename that to filename.
On Thu Jan 08 2015 at 12:21:18 PM Anand Avati av...@gluster.org wrote:
Ideally you want the clients to coordinate among themselves. Note that
this feature cannot be implemented
It would be convenient if the time is appended to the snap name on the fly
(when receiving list of snap names from glusterd?) so that the timezone
application can be dynamic (which is what users would expect).
Thanks
On Thu Jan 08 2015 at 3:21:15 AM Poornima Gurusiddaiah pguru...@redhat.com
Ideally you want the clients to coordinate among themselves. Note that this
feature cannot be implemented foolproof (theoretically) in a system that
supports NFSv3.
On Thu Jan 08 2015 at 8:57:48 AM Harmeet Kalsi kharm...@hotmail.com wrote:
Hi Anand, that was spot on. Any idea if there will be
Please review http://review.gluster.org/9332/, as it undoes the
introduction of itransform on d_off in AFR. This does not solve
DHT-over-DHT or other future use cases, but at least fixes the regression
in 3.6.x.
Thanks
On Tue Dec 23 2014 at 10:34:41 AM Anand Avati av...@gluster.org wrote
This is indeed a misuse. A very similar bug used to be there in io-threads,
but we have moved to using pthread_cond over there since a while.
To fix this problem we could use a pthread_mutex/pthread_cond pair + a
boolean flag in place of the misused mutex. Or, we could just declare
gd_op_sm_lock
On Tue Nov 25 2014 at 1:28:59 PM Shyam srang...@redhat.com wrote:
On 11/12/2014 01:55 AM, Anand Avati wrote:
On Tue, Nov 11, 2014 at 1:56 PM, Jeff Darcy jda...@redhat.com
mailto:jda...@redhat.com wrote:
(Personally I would have
done this by mixing in the parent GFID
On Tue, Oct 14, 2014 at 7:22 PM, Emmanuel Dreyfus m...@netbsd.org wrote:
J. Bruce Fields bfie...@fieldses.org wrote:
Is the result on non-Linux really to fail any readdir using an offset
not returned from the current open?
Yes, but thatnon-Linux behabvior is POSIX compliant. Linux just
On Mon, Oct 13, 2014 at 2:00 PM, Shyam srang...@redhat.com wrote:
(apologies, last one on the metrics from me :), as I believe it is more
about style than actual numbers at a point)
_maybe_ this is better, and it is pretty close to call now ;)
find -name '*.c' | xargs grep else | wc -l
On Mon, Sep 1, 2014 at 6:07 AM, Vimal A R arvi...@yahoo.in wrote:
Hello fuse-devel / fs-cache / gluster-devel lists,
I would like to propose the idea of implementing FS-Cache support in the
fuse kernel module, which I am planning to do as part of my UG university
course. This proposal is by
+1 for all the points.
On Wed, Aug 13, 2014 at 11:22 AM, Jeff Darcy jda...@redhat.com wrote:
I.1 Generating the master volume key
Master volume key should be generated by user on the trusted machine.
Recommendations on master key generation provided at section 6.2 of
the
On Tue, Aug 12, 2014 at 9:58 AM, Emmanuel Dreyfus m...@netbsd.org wrote:
On Mon, Aug 11, 2014 at 09:53:19PM -0700, Anand Avati wrote:
If FUSE implements proper direct_io semantics (somewhat like how O_DIRECT
flag is handled) and allows the mode to be enabled by the FS in open_cbk,
then I
On Wed, Aug 13, 2014 at 8:55 PM, Emmanuel Dreyfus m...@netbsd.org wrote:
Anand Avati av...@gluster.org wrote:
That may / may not work well in practice depending on the number of
concurrent apps working on a file.
I am not sure what could make a FS decide that for the same file, one
file
My guess would be that direct_io_mode works differently on *BSD. In Linux
(and it appears in OS/X as well), the VFS takes hint from the file size
(returned in lookup/stat) to limit itself from not read()ing beyond that
offset. So if a file size is returned 0 in lookup, read() is never received
On Mon, Aug 11, 2014 at 7:37 PM, Harshavardhana har...@harshavardhana.net
wrote:
But there is something I don't get withthe fix:
- the code forces direct IO if (state-flags O_ACCMODE) != O_RDONLY),
but here the file is open read/only, hence I would expect fuse xlator to
do nothing
On Mon, Aug 11, 2014 at 9:14 PM, Emmanuel Dreyfus m...@netbsd.org wrote:
Anand Avati av...@gluster.org wrote:
In meta all file sizes are 0 (since the contents of the inode are
generated
dynamically on open()/read(), size is unknown during lookup() -- just
like
/proc). And therefore all
David,
Is it possible to profile the app to understand the block sizes used for
performing write() (using strace, source code inspection etc)? The block
sizes reported by gluster volume profile is measured on the server side and
is subject to some aggregation by the client side write-behind
Can you add more logging to the fd migration failure path as well please
(errno and possibly other details)?
Thanks!
On Wed, Aug 6, 2014 at 9:16 PM, Pranith Kumar Karampuri pkara...@redhat.com
wrote:
hi,
Could you guys review http://review.gluster.com/#/c/8402. This fixes
crash reported
There are subtle differences between fuse and server. In fuse the inode
table does not use LRU pruning, so expected inodes are guaranteed to be
cached. For e.g, when mkdir() FOP arrives, fuse would have already checked
with a lookup and the kernel guarantees another thread would not have
created
call frames and stacks are re-used from a mem-pool. So pointers might
repeat. Can you describe your use case a little more in detail, just to be
sure?
On Mon, Jul 28, 2014 at 11:27 AM, Matthew McKeen matt...@mmckeen.net
wrote:
Is it true that different fops will always have a different frame
28, 2014 at 12:19 PM, Anand Avati av...@gluster.org wrote:
call frames and stacks are re-used from a mem-pool. So pointers might
repeat. Can you describe your use case a little more in detail, just to
be
sure?
On Mon, Jul 28, 2014 at 11:27 AM, Matthew McKeen matt...@mmckeen.net
wrote
On Tue, Jul 22, 2014 at 7:35 AM, Kaushal M kshlms...@gmail.com wrote:
Hey everyone,
While I was writing the documentation for the options framework, I
thought up of a way to better organize the code documentation we are
creating now. I've posted a patch for review that implements this
Copying gluster-devel@
Thanks for reporting Michael. I guess we need to forward port that old
change. Can you please send out a patch to gerrit?
Thanks!
On 7/16/14, 2:36 AM, 马忠 wrote:
Hi Avati,
I tried to build the latest glusterfs 3.5.1 on solaris11.1, but
it stopped because of
On Mon, Jul 7, 2014 at 12:48 PM, Raghavendra Bhat rab...@redhat.com wrote:
Hi,
As per my understanding nfs server is not doing inode linking in readdirp
callback. Because of this there might be some errors while dealing with
virtual inodes (or gfids). As of now meta, gfid-access and
On Fri, Jul 4, 2014 at 8:17 PM, Pranith Kumar Karampuri pkara...@redhat.com
wrote:
On 07/05/2014 08:17 AM, Anand Avati wrote:
On Fri, Jul 4, 2014 at 7:03 PM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
hi,
I work on glusterfs and was debugging a memory leak. Need your help
is going back to the application.
Fix: if revalidation is happening with LOOKUP_REVAL, then ignore
entry-timeout and always do the up-call.
Signed-off-by: Anand Avati av...@redhat.com
---
fs/fuse/dir.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/fuse/dir.c b/fs
On 6/3/14, 11:32 PM, Pranith Kumar Karampuri wrote:
On 06/04/2014 11:37 AM, Krutika Dhananjay wrote:
Hi,
Recently there was a crash in locks translator (BZ 1103347, BZ
1097102) with the following backtrace:
(gdb) bt
#0 uuid_unpack (in=0x8 Address 0x8 out of bounds,
uu=0x7fffea6c6a60) at
On 6/4/14, 9:43 PM, Krutika Dhananjay wrote:
*From: *Pranith Kumar Karampuri pkara...@redhat.com
*To: *Krutika Dhananjay kdhan...@redhat.com, Anand Avati
aav...@redhat.com
*Cc: *gluster-devel@gluster.org
Niels,
This is a good addition. While gluster clients do a reasonably good job at
detecting dead/hung servers with ping-timeout, the server side detection
has been rather weak. TCP_KEEPALIVE has helped to some extent, for cases
where an idling client (which holds a lock) goes dead. However if an
KP, Vipul,
It will be awesome to get io-stats like instrumentation on the client side.
Here are some further thoughts on how to implement that. If you have a
recent git HEAD build, I would suggest that you explore the latency stats
on the client side exposed through meta at
On Thu, May 15, 2014 at 5:49 PM, Pranith Kumar Karampuri
pkara...@redhat.com wrote:
hi,
In the latest build I fired for review.gluster.com/7766 (
http://build.gluster.org/job/regression/4443/console) failed because of
spurious failure. The script doesn't wait for nfs export to be
On Mon, May 12, 2014 at 4:23 PM, Justin Clift jus...@gluster.org wrote:
On 12/05/2014, at 9:04 PM, Anand Avati wrote:
snip
And yeah, the other reason: if a dev pushes a series/set of dependent
patches, regression needs to run only on the last one (regression
test/voting is cumulative
On Sun, May 4, 2014 at 9:22 AM, Niels de Vos nde...@redhat.com wrote:
Hi,
bug 1093324 has been opened and we have identified the following cause:
1. an NFS-client does a LOOKUP of a directory on a volume
2. the NFS-client receives a filehandle (contains volume-id + GFID)
3. add-brick is
39 matches
Mail list logo
