On 07/03/2014 02:24 PM, Xavier Hernandez wrote:
On Thursday 03 July 2014 07:40:45 Pranith Kumar Karampuri wrote:
On 07/01/2014 04:52 PM, Xavier Hernandez wrote:
Hi,
current implementation of ec xlator uses inodelk/entrylk before each
operation to guarantee exclusive access to the inode. This
On Thursday 03 July 2014 07:40:45 Pranith Kumar Karampuri wrote:
> On 07/01/2014 04:52 PM, Xavier Hernandez wrote:
> > Hi,
> >
> > current implementation of ec xlator uses inodelk/entrylk before each
> > operation to guarantee exclusive access to the inode. This implementation
> > blocks any other
On 07/01/2014 04:52 PM, Xavier Hernandez wrote:
Hi,
current implementation of ec xlator uses inodelk/entrylk before each operation
to guarantee exclusive access to the inode. This implementation blocks any
other request to the same inode/entry until the previous operation has
completed and unlo
On Tuesday 01 July 2014 21:37:57 haiwei.xie-soulinfo wrote:
> hi Xavi,
>
>Writev inodelk lock whole file, so write speed is bad. If
> inodelk(offset,len), IDA_KEY_SIZE xattr will be not consistent crossing
> bricks from unorder writev.
>
>So how about just use IDA_KEY_VERSION and bricks i
hi Xavi,
Writev inodelk lock whole file, so write speed is bad. If
inodelk(offset,len),
IDA_KEY_SIZE xattr will be not consistent crossing bricks from unorder writev.
So how about just use IDA_KEY_VERSION and bricks ia_size to check data crash?
Drop IDA_KEY_SIZE, and lookup lock whole fi
Hi,
current implementation of ec xlator uses inodelk/entrylk before each operation
to guarantee exclusive access to the inode. This implementation blocks any
other request to the same inode/entry until the previous operation has
completed and unlocked it.
This adds a lot of latency to each ope
