Hi Kotresh,
I have had to make a similar decision in the implementation of libgfsys [1].
Looking at
what can fail in these function calls, it's clear that only a bug (i.e. a call
to
pthread_mutex_lock() with an uninitialized mutex or a bad pointer, or bad
designed
code) can generate an error
Hi,
I've just uploaded the gfsys library to gerrit for review [1].
It's basically a support library used by other xlators like dfc and ida (they
will
also be uploaded for review very soon).
libgfsys is basically intended to easily handle errors with good tracing
capabilities and adds or expan
Hi Jeff,
El 13/02/14 14:18, Jeff Darcy ha escrit:
I've been able to do the first performance comparison of a dispersed
volume. The translators still have known problems that will be solved as
soon as possible, but at least they support simple tests. I used a very
simple configuration and I compa
Hi Niels,
El 10/02/14 11:05, Niels de Vos ha escrit:
On Tue, Feb 04, 2014 at 10:07:22AM +0100, Xavier Hernandez wrote:
Hi,
currently, inodelk() and entrylk() are being used to make sure that
changes happen synchronously on all bricks, avoiding data/metadata
corruption when multiple clients
delegating locks to clients,
and build caching coherency protocols / oplocks / inodelk avoidence on
top of it.
Feel free to share a more detailed proposal if you have have/plan -
I'm sure the Samba folks (Ira copied) would be interested too.
Thanks!
Avati
On Wed, Feb 5, 2014 at 11:27 AM,
p of it.
Feel free to share a more detailed proposal if you have have/plan -
I'm sure the Samba folks (Ira copied) would be interested too.
Thanks!
Avati
On Wed, Feb 5, 2014 at 11:27 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
On 04
anted to propose the idea to see if it could be valid or not
before spending too much of my scarce time working on it. I'll try to
get a more detailed picture to discuss it.
Best regards,
Xavi
Thanks!
Avati
On Wed, Feb 5, 2014 at 11:27 AM, Xavier Hernandez
mailto:xhernan...@dat
On 04.02.2014 17:18, Jeff Darcy wrote:
The only synchronization point needed is to make sure that all
bricks
agree on the inode state and which client owns it. This can be
achieved
without locking using a method similar to what I implemented in the
DFC
translator. Besides the lock-less archite
Hi,
currently, inodelk() and entrylk() are being used to make sure that
changes happen synchronously on all bricks, avoiding data/metadata
corruption when multiple clients modify the same inode concurrently. So
far so good, however I think this introduces a significant overhead to
avoid a sit
El 03/01/14 07:02, Harshavardhana ha escrit:
assert() macro also behaves in the same manner. It is an usual practice to
have assert() be a NOOP in production builds. assert()'s normal usage is to
assert that the expression is TRUE and it _should_ not be considered as a
replacement for NULL point
I missed the const attribute. Thanks for the explanation. This should
eliminate the THIS problem, as you proved, however other cases are still
possible that won't work correctly.
Basically, any TLS pointer passed to user code instead of being
dereferenced will have problems. In this case, uuid
Hi Pranith,
it's really a very interesting and hard to find bug, but I'm wondering
how we can prevent this to happen in the general case. There might be
other operations based on pointers to thread local storage that will
suffer this problem. Probably 'errno' is one of the most dangerous, but
Al 12/09/13 13:17, En/na Brian Foster ha escrit:
On 09/12/2013 06:08 AM, Xavier Hernandez wrote:
Al 09/09/13 17:25, En/na Vijay Bellur ha escrit:
On 09/09/2013 02:18 PM, Xavier Hernandez wrote:
Al 06/09/13 20:43, En/na Anand Avati ha escrit:
On Fri, Sep 6, 2013 at 1:46 AM, Xavier Hernandez
Al 09/09/13 17:25, En/na Vijay Bellur ha escrit:
On 09/09/2013 02:18 PM, Xavier Hernandez wrote:
Al 06/09/13 20:43, En/na Anand Avati ha escrit:
On Fri, Sep 6, 2013 at 1:46 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Al 04/09/13 18:10, En/na Anand Avati ha escrit:
Al 09/09/13 17:25, En/na Vijay Bellur ha escrit:
On 09/09/2013 02:18 PM, Xavier Hernandez wrote:
Al 06/09/13 20:43, En/na Anand Avati ha escrit:
On Fri, Sep 6, 2013 at 1:46 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Al 04/09/13 18:10, En/na Anand Avati ha escrit:
Al 06/09/13 20:43, En/na Anand Avati ha escrit:
On Fri, Sep 6, 2013 at 1:46 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Al 04/09/13 18:10, En/na Anand Avati ha escrit:
On Wed, Sep 4, 2013 at 6:37 AM, Xavier Hernandez
mailto:xhernan...@datalab.es&g
Al 04/09/13 18:10, En/na Anand Avati ha escrit:
On Wed, Sep 4, 2013 at 6:37 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Al 04/09/13 14:05, En/na Jeff Darcy ha escrit:
On 09/04/2013 04:27 AM, Xavier Hernandez wrote:
I would also like to note tha
Al 04/09/13 14:05, En/na Jeff Darcy ha escrit:
On 09/04/2013 04:27 AM, Xavier Hernandez wrote:
I would also like to note that each node can store multiple elements.
Current implementation creates a node for each byte in the key. In my
implementation I only create a node if there is a prefix
indirections.
Each node stores the key from the beginning to allow very fast lookup by
a single memcmp().
In normal situations, this implementation is very fast and very
efficient in space.
Greetings,
Xavi
Al 04/09/13 10:10, En/na Xavier Hernandez ha escrit:
Al 04/09/13 02:55, En/na Anand Avati ha
Al 04/09/13 02:55, En/na Anand Avati ha escrit:
On Tue, Sep 3, 2013 at 1:42 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Al 03/09/13 09:33, En/na Anand Avati ha escrit:
On Mon, Sep 2, 2013 at 7:24 AM, Xavier Hernandez
mailto:xhernan...@datalab.es&g
Al 03/09/13 09:33, En/na Anand Avati ha escrit:
On Mon, Sep 2, 2013 at 7:24 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Hi,
dict_t structures are widely used in glusterfs. I've some ideas
that could improve its performance.
* On delete operations,
Hi,
dict_t structures are widely used in glusterfs. I've some ideas that
could improve its performance.
* On delete operations, return the current value if it exists.
This is very useful when we want to get a value and remove it from the
dictionary. This way it can be done accessing and lock
Maybe a different approach could solve some of these problems and
improve responsiveness. It's an architectural change so I'm not sure if
it's the right moment to discuss it, but at least it could be considered
for the future. There are a lot of details to consider, so do not take
this as a ful
cope of gfsck, so that I could share the ideas with you.
With regards,
Shishir
- Original Message -
From: "Xavier Hernandez"
To: "Krishnan Parthasarathi"
Cc: gluster-devel@nongnu.org
Sent: Monday, April 22, 2013 7:20:36 PM
Subject: Re: [Gluster-devel] GlusterFS pro
I've just added 'gfsck', a tool to check file system integrity and
repair any detected error.
I'm already working on it.
Xavi
Al 22/04/13 15:03, En/na Krishnan Parthasarathi ha escrit:
Hi All,
I am trying to collect all GlusterFS project ideas into a single page
in the wiki, here:
http://w
un to see where most of the
time is getting spent?
Avati
On Tue, Mar 26, 2013 at 11:01 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Hi,
since one of the improvements seemed to be the reduction of the
number of directories inside .glusterfs I've made a mo
nd ls take 0.9 seconds; the third 9.
I don't know what causes such slowness on the third ls, however the
second ls has improved a lot.
Any one has some advice ?
Is there any way to improve this ? some tweak of the kernel/xfs/gluster ?
Thanks,
Xavi
Al 26/03/13 11:02, En/na Xavier He
Hi,
I've reproduced a problem I've seen with directory listing of
directories not accessed for a long time (some hours). Gluster version
is 3.3.1.
I've made the tests with different hardware and the behavior is quite
similar.
The problem can be clearly seen doing this:
1. Format bricks wi
fuse, It uses the max_read=128KB option. Any big
request would be split. Tuning the option, it will be faster in big
read and write, but no use for small files.
At 2013-03-11 18:49:47,"Xavier Hernandez" wrote:
>Hello,
>
>I've recently performed some tests with glust
Hello,
I've recently performed some tests with gluster on a fast network (IP
over infiniband) and got some unexpected results. It seems that
mount/fuse is becoming a bottleneck when the network and disk are very fast.
I started with a simple distributed volume with 2 bricks mounted on a
ramd
Hi all,
We have published an initial version (proof of concept) of the
disperse translator on github (https://github.com/datalab-bcn). It is a
new GlusterFS translator with a level of fault tolerance configurable at
creation time, but with a minimal waste of physical disk space (it's
conceptual
Hello Gustavo,
first of all you don't need to call iov_dup() unless you modify it
before WIND() or you need it at the callback. If you need to make some
changes to the vector list, then you mush call iov_dup(), make the
changes, call one or more WINDs() (if needed) and free it with
GF_FREE().
On 05/24/2012 03:05 PM, Jeff Darcy wrote:
On 05/24/2012 03:10 AM, Xavier Hernandez wrote:
preparent and postparent have the attributes (modification time, size,
permissions, ...) of the parent directory of the file being modified
before and after the modification is done.
Thank you, Xavi
On 05/24/2012 03:31 AM, Emmanuel Dreyfus wrote:
Jeff Darcy wrote:
in the protocol/server xlator, there are many occurences where
callbacks have a struct iatt for preparent and postparent. What are
these for?
NFS needs them to support its style of caching.
Let me rephrase: what information is
On 05/22/2012 09:48 AM, Anand Avati wrote:
I've tried to understand how AFR works and, in some way, some of
the ideas have been taken from it. However it is very complex and
a lot of changes have been carried out in the master branch over
the latest months. It's hard for me to
On 05/22/2012 02:11 AM, Anand Avati wrote:
On Tue, May 8, 2012 at 2:34 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Hello developers,
I would like to expose some ideas we are working on to create a
new kind of translator that should be able to unify and si
omprehensive list of iatt
returning fops from the examples ... but I'd say it'll
take a solid peer review to get this hammered out
properly.
Thanks for steering me straight Xavi, appreciate
it.
- Original Message -
From: "Xavier Hernandez"
To: "Ian Latter"
Subj
riginal Message -
From: "Xavier Hernandez"
To:
Subject: Re: [Gluster-devel] lseek
Date: Mon, 14 May 2012 09:48:17 +0200
Hello Ian,
there is no such thing as an explicit seek in glusterfs.
Each readv,
writev, (f)truncate and rchecksum have an offset parameter
that tells
you the pos
Hello Ian,
there is no such thing as an explicit seek in glusterfs. Each readv,
writev, (f)truncate and rchecksum have an offset parameter that tells
you the position where the operation must be performed.
If you make something that changes the size of the file you must make it
in a way that
Hello developers,
I would like to expose some ideas we are working on to create a new kind
of translator that should be able to unify and simplify to some extent
the healing procedures of complex translators.
Currently, the only translator with complex healing capabilities that we
are aware
On 05/05/2012 08:02 AM, Anand Avati wrote:
On Wed, May 2, 2012 at 3:55 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Hello,
I'm wondering if there are any requisites that translators must
satisfy to work correctly inside glusterfs.
In particular I n
Hello,
I'm wondering if there are any requisites that translators must satisfy
to work correctly inside glusterfs.
In particular I need to know two things:
1. Are translators required to respect the order in which they receive
the requests ?
This is specially important in translators such
this correct ?
Xavi
On 04/03/2012 05:20 PM, Xavier Hernandez wrote:
On 04/03/2012 04:53 PM, Anand Avati wrote:
On Tue, Apr 3, 2012 at 6:20 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Hello developers,
I'm currently trying to implement a new method for managi
On 04/03/2012 04:53 PM, Anand Avati wrote:
On Tue, Apr 3, 2012 at 6:20 AM, Xavier Hernandez
mailto:xhernan...@datalab.es>> wrote:
Hello developers,
I'm currently trying to implement a new method for managing inode
and entry modifications that will be faster (I hop
Hello developers,
I'm currently trying to implement a new method for managing inode and
entry modifications that will be faster (I hope) than the current method
for the most common cases. To do so I need to know exactly how the
locking mechanism works. I have been browsing the source code and
Thanks. I'll keep you posted.
On 30.03.2012 13:39, Anand Babu
Periasamy wrote:
> Xavier, this sounds cool. Please keep me and John
Mark in the loop. We
> will make sure you are getting all the help you
needed from Red Hat.
> -ab
___
Gluster-devel
t; it
sounds pretty interesting to me.
> Will you publish any news on this
mailing list or is there another
> place where I can update my self
about your progress?
>
> Am Fri, 30 Mar 2012 08:33:37 +0200
> schrieb
Xavier Hernandez
> :
>
>> Sorry, the previous
message was
Sorry, the previous message was intended for Pascal.
Xavi
On
30.03.2012 08:29, Xavier Hernandez wrote:
> Hello David,
>
> we
aren't the core developers of GlusterFS, but we are developing a new
translator that will be able to implement something similar to a RAID6.
In fact i
Hello David,
we aren't the core developers of GlusterFS, but we are
developing a new translator that will be able to implement something
similar to a RAID6. In fact it will be able to have a configurable level
of redundacy. A redundancy of 1 is equivalent to RAID 5; a redundancy of
2 is equival
Hello again,
I'm trying to implement self-healing functionality in my translator.
I've been browsing source code (basically mount/fuse and cluster/afr
translators) and I see that fuse seems to always make a lookup call each
time it sees a file or directory, at least the first time. If that's
On 10.03.2012 21:34, Anand Avati wrote:
> There is a no rule
written on stone here. It is good practice to make
>
> copies. Note
that for things like iatt structure, you need not
> "allocate" and
"free" from the heap. Most of the time you can copy to
> a structure on
the stack, modify and ret
Hello,
I've a doubt about the way in which arguments received from upper or
lower translators should be handled in case they need to be modified.
Simple arguments are passed by value and there is no problem, but all
other data types are passed by reference (dict_t *, fd_t *, inode_t *,
struc
I've just tried again to use the dict_t argument of dirreadp with
the head of master branch and now it works correctly.
Thanks
On
01.03.2012 18:45, Amar Tumballi wrote:
> On 03/01/2012 10:11 PM,
Xavier Hernandez wrote:
>
>> Thank you very much. In readdirp I always
recei
When I tried this I was using master branch but from two or three
weeks ago. Yesterday I updated to head. I'll repeat the tests with this
version.
Thanks
On 01.03.2012 18:45, Amar Tumballi wrote:
> On
03/01/2012 10:11 PM, Xavier Hernandez wrote:
>
>> Thank you very mu
that it really should fill in the requested attributes,
so probably I made some error when I tested this. I will repeat the
tests.
Thanks
On 01.03.2012 18:07, Anand Avati wrote:
> Please find
answers inline.
>
> On Wed, Feb 29, 2012 at 7:16 AM, Xavier Hernandez
wrote:
>
>&
Hello gluster developers,
I'm working on a new translator that needs to implement locking
strategies over inodes and directory entries for some file operations.
The translator uses multiple subvolumes.
I've been searching internet and browsing source code but there are
some aspects that I ca
56 matches
Mail list logo
