On 2018/8/12 下午12:18, Dan Merillat wrote:
> On Sat, Aug 11, 2018 at 9:36 PM Qu Wenruo wrote:
>
>>> I'll add a new rescue subcommand, 'btrfs rescue disable-quota' for you
>>> to disable quota offline.
>>
>> Patch set (from my work mailbox), titled "[PATCH] btrfs-progs: rescue:
>> Add ability to
On Sat, Aug 11, 2018 at 9:36 PM Qu Wenruo wrote:
> > I'll add a new rescue subcommand, 'btrfs rescue disable-quota' for you
> > to disable quota offline.
>
> Patch set (from my work mailbox), titled "[PATCH] btrfs-progs: rescue:
> Add ability to disable quota offline".
> Can also be fetched from
On Sat, Aug 11, 2018 at 9:34 PM Qu Wenruo wrote:
>
> Provide an offline tool to disable quota.
>
> For kernel which skip_balance doesn't work, there is no way to disable
> quota on huge fs with balance, as quota will cause balance to hang for a
> long long time for each tree block switch.
>
> So a
On Fri, Aug 10, 2018 at 9:29 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Fri, 10 Aug 2018 12:07:34 -0600 as excerpted:
>
>> But whether data is shared or exclusive seems potentially ephemeral, and
>> not something a sysadmin should even be able to anticipate let alone
>> indiv
On 2018/8/12 上午8:30, Qu Wenruo wrote:
>
>
> On 2018/8/12 上午5:10, Dan Merillat wrote:
>> 19 hours later, still going extremely slowly and taking longer and
>> longer for progress made. Main symptom is the mount process is
>> spinning at 100% CPU, interspersed with btrfs-transaction spinning at
Provide an offline tool to disable quota.
For kernel which skip_balance doesn't work, there is no way to disable
quota on huge fs with balance, as quota will cause balance to hang for a
long long time for each tree block switch.
So add an offline rescue tool to disable quota.
Reported-by: Dan Me
On 2018/8/12 上午8:59, Dan Merillat wrote:
> On Sat, Aug 11, 2018 at 8:30 PM Qu Wenruo wrote:
>>
>> It looks pretty like qgroup, but too many noise.
>> The pin point trace event would btrfs_find_all_roots().
>
> I had this half-written when you replied.
>
> Agreed: looks like bulk of time spent
On Sat, Aug 11, 2018 at 8:30 PM Qu Wenruo wrote:
>
> It looks pretty like qgroup, but too many noise.
> The pin point trace event would btrfs_find_all_roots().
I had this half-written when you replied.
Agreed: looks like bulk of time spent resides in qgroups. Spent some
time with sysrq-l and ft
On 2018/8/12 上午5:10, Dan Merillat wrote:
> 19 hours later, still going extremely slowly and taking longer and
> longer for progress made. Main symptom is the mount process is
> spinning at 100% CPU, interspersed with btrfs-transaction spinning at
> 100% CPU.
> So far it's racked up 14h45m of CPU
19 hours later, still going extremely slowly and taking longer and
longer for progress made. Main symptom is the mount process is
spinning at 100% CPU, interspersed with btrfs-transaction spinning at
100% CPU.
So far it's racked up 14h45m of CPU time on mount and an additional
3h40m on btrfs-trans
On Sat, Aug 11, 2018 at 08:27:04AM +0200, erentheti...@mail.de wrote:
> I guess that covers most topics, two last questions:
>
> Will the write hole behave differently on Raid 6 compared to Raid 5 ?
Not really. It changes the probability distribution (you get an extra
chance to recover using a p
11 matches
Mail list logo
