At 08/24/2016 02:38 AM, Rakesh Sankeshi wrote:
sorry, was out of the town.
not much load on the system at all.
As we are hitting many issues in production, just using this system
for my test purpose. Built few different filesystems. 1 with LZO
compression, second one with ZLIB and third one w
sorry, was out of the town.
not much load on the system at all.
As we are hitting many issues in production, just using this system
for my test purpose. Built few different filesystems. 1 with LZO
compression, second one with ZLIB and third one without any
compression. All has issues related to q
At 08/17/2016 12:05 AM, Rakesh Sankeshi wrote:
2) after EDQUOT, can't write anymore.
I can delete the data, but still can't write further
So it's a underflow now.
3) tested it without compression and also with LZO and ZLIB.. all
behave same way with qgroup. no consistency on when it hits
On 08/16/2016 16:33 -0700, Rakesh Sankeshi wrote:
>> also is there any timeframe on when the qgroup / quota issues would be
>> stabilized in btrfs?
>>
>> Thanks!
This may or may not be of interest to you, but for the record, since at least
linux 4.2, I've had pretty good luc
also is there any timeframe on when the qgroup / quota issues would be
stabilized in btrfs?
Thanks!
On Tue, Aug 16, 2016 at 9:05 AM, Rakesh Sankeshi
wrote:
> 2) after EDQUOT, can't write anymore.
>
> I can delete the data, but still can't write further
>
> 3) tested it without compression and a
2) after EDQUOT, can't write anymore.
I can delete the data, but still can't write further
3) tested it without compression and also with LZO and ZLIB.. all
behave same way with qgroup. no consistency on when it hits the quota
limit and don't understand on how it's calculating the numbers.
In ca
At 08/16/2016 03:11 AM, Rakesh Sankeshi wrote:
yes, subvol level.
qgroupid rfer excl max_rfer max_excl parent child
-- -
0/5 16.00KiB 16.00KiB none none --- ---
0/
yes, subvol level.
qgroupid rfer excl max_rfer max_excl parent child
-- -
0/5 16.00KiB 16.00KiB none none --- ---
0/258 119.48GiB119.48GiB200.00GiB
At 08/12/2016 01:32 AM, Rakesh Sankeshi wrote:
I set 200GB limit to one user and 100GB to another user.
as soon as I reached 139GB and 53GB each, hitting the quota errors.
anyway to workaround quota functionality on btrfs LZO compressed
filesystem?
Please paste "btrfs qgroup show -prce " ou
Rakesh Sankeshi posted on Fri, 12 Aug 2016 08:47:13 -0700 as excerpted:
> Another question I had was, is there any way to check what's the
> directory/file sizes prior to compression and how much copression btrfs
> did, etc? Basicaly some stats around compression and/or dedupe from
> btrfs.
There
Thanks for your inputs.
Another question I had was, is there any way to check what's the
directory/file sizes prior to compression and how much copression
btrfs did, etc? Basicaly some stats around compression and/or dedupe
from btrfs.
On Thu, Aug 11, 2016 at 12:13 PM, Duncan <1i5t5.dun...@cox.n
Rakesh Sankeshi posted on Thu, 11 Aug 2016 10:32:03 -0700 as excerpted:
> I set 200GB limit to one user and 100GB to another user.
>
> as soon as I reached 139GB and 53GB each, hitting the quota errors.
> anyway to workaround quota functionality on btrfs LZO compressed
> filesystem?
The btrfs qu
I set 200GB limit to one user and 100GB to another user.
as soon as I reached 139GB and 53GB each, hitting the quota errors.
anyway to workaround quota functionality on btrfs LZO compressed
filesystem?
4.7.0-040700-generic #201608021801 SMP
btrfs-progs v4.7
Label: none uuid: 66a78faf-2052-4
OK, thanks.
On 11.03.2013 15:35, Wang Shilong wrote:
>
>> On 11.03.2013 15:15, Wang Shilong wrote:
>>>
>>>
>>>
> The worst thing is that i don't think users can master this magic
> concept very well.
Normally users don't need very sophisticated scenarios. In fact, they
don't even need
> On 11.03.2013 15:15, Wang Shilong wrote:
>>
>>
>>
The worst thing is that i don't think users can master this magic
concept very well.
>>>
>>> Normally users don't need very sophisticated scenarios. In fact, they
>>> don't even need higher level quota groups, the basic tracking is
On 11.03.2013 15:15, Wang Shilong wrote:
>
>
>
>>> The worst thing is that i don't think users can master this magic
>>> concept very well.
>>
>> Normally users don't need very sophisticated scenarios. In fact, they
>> don't even need higher level quota groups, the basic tracking is
>> enough. I
>> The worst thing is that i don't think users can master this magic
>> concept very well.
>
> Normally users don't need very sophisticated scenarios. In fact, they
> don't even need higher level quota groups, the basic tracking is
> enough. In this case, everything just works as expected for t
On 11.03.2013 14:31, Wang Shilong wrote:
>
> Hello,
>
>>>
>>> In fact, i think you try to put some work on users, especially when
>>> snapshot happens.
>>> It is complex to track all the group's accounting when having
>>> snapshots..See the following
>>> commands.
>>>
>>> btrfs sub snapshot -c
Hello,
> On 10.03.2013 05:21, Shilong Wang wrote:
>> Hello, Arne
>>
>> Steps to reproduce:
>>
>>
>>mkfs.btrfs
>>mount
>>btrfs quota enable
>>
>>btrfs sub create /sub
>>btrfs qgroup create 1/1
>>
On 10.03.2013 05:21, Shilong Wang wrote:
> Hello, Arne
>
> Steps to reproduce:
>
>
> mkfs.btrfs
> mount
> btrfs quota enable
>
> btrfs sub create /sub
> btrfs qgroup create 1/1
> btrfs
ping..
> Hello, Arne
>
> Steps to reproduce:
>
>
>mkfs.btrfs
>mount
>btrfs quota enable
>
>btrfs sub create /sub
>btrfs qgroup create 1/1
>btrfs qgroup assign sub_qgroupid 1/1
>
>
>
22 matches
Mail list logo
