[Gluster-devel] [Questions] why shard feature doesn't support quota

[Krutika Dhananjay]

On Thu, Jun 29, 2017 at 1:47 PM, Xie Changlong <xiechanglong.d at gmail.com>
wrote:

> Hi Krutika
>
> Thanks for your quick response!
>
> 在 6/29/2017 3:24 PM, Krutika Dhananjay 写道:
>
>> This is based on my high-level understanding of quota in gluster -
>> supporting quota on sharded volumes will require us to make quota xlator
>> account for shards residing under the hidden ".shard" directory per file
>> and adding this to the quota-xattr representing aggregated consumed size on
>> the parent directory of the original file.
>>
>> This isn't hard to do. But at the moment we support sharding only for VM
>> image store use case.
>>
>
> Why sharding only support VM large images? It's interesting. More, are
> there other limits for sharding usage? We want to reduce data
> reconstruction time with sharding, as you know it takes too long time to
> recover data with raid, and sharding is a good choice to us.
>

Yes, at the moment it "works" only for single-writer large file use cases -
VM image store being the most common workload among them.
For a long time, one of the main complaints users had with gluster was slow
heals for large size VM images. Our immediate focus at that time was to
introduce shard for VM use case.

One of the main issues with multiple writers is ordering updates to the
aggregated size xattr - which is a global metadata - following every file
data modification operation, without compromising on performance.

>
> There are plans to make shard useful for more generic use cases in the
>> near term. When we get there, we will support quota too on sharded files.
>>
>
> That's a *good* news. BTW we also have a plan to implement this part. Any
> suggestions?
>

That's nice. We could have a chat on #gluster-dev in Freenode if you want.

-Krutika


>
>> -Krutika
>>
>>
> --
> Thanks
>     -Xie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170630/599409bd/attachment-0001.html>