At 05/05/2017 10:40 AM, Marc MERLIN wrote:
On Fri, May 05, 2017 at 09:19:29AM +0800, Qu Wenruo wrote:
Sorry for not noticing the link.
no problem, it was only one line amongst many :)
Thanks much for having had a look.
[Conclusion]
After checking the full result, some of fs/subvolume tre
On Fri, May 05, 2017 at 09:19:29AM +0800, Qu Wenruo wrote:
> Sorry for not noticing the link.
no problem, it was only one line amongst many :)
Thanks much for having had a look.
> [Conclusion]
> After checking the full result, some of fs/subvolume trees are corrupted.
>
> [Details]
> Some examp
At 05/05/2017 09:19 AM, Qu Wenruo wrote:
At 05/02/2017 11:23 AM, Marc MERLIN wrote:
Hi Chris,
Thanks for the reply, much appreciated.
On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote:
What about btfs check (no repair), without and then also with
--mode=lowmem?
In theory I li
Commit 81fb6f77a026 (btrfs: qgroup: Add new trace point for
qgroup data reserve) added the following events which aren't used.
btrfs__qgroup_data_map
btrfs_qgroup_init_data_rsv_map
btrfs_qgroup_free_data_rsv_map
So remove them.
Signed-off-by: Anand Jain
cc: quwen...@cn.fujitsu.com
Reviewe
At 05/02/2017 11:23 AM, Marc MERLIN wrote:
Hi Chris,
Thanks for the reply, much appreciated.
On Mon, May 01, 2017 at 07:50:22PM -0600, Chris Murphy wrote:
What about btfs check (no repair), without and then also with --mode=lowmem?
In theory I like the idea of a 24 hour rollback; but in nor
At 05/02/2017 02:08 AM, Marc MERLIN wrote:
So, I forgot to mention that it's my main media and backup server that got
corrupted. Yes, I do actually have a backup of a backup server, but it's
going to take days to recover due to the amount of data to copy back, not
counting lots of manual typing
At 05/05/2017 01:29 AM, Kai Krakow wrote:
Hello!
Since I saw a few kernel freezes lately (due to experimenting with
ck-sources) including some filesystem-related backtraces, I booted my
rescue system to check my btrfs filesystem.
Luckily, it showed no problems. It said, everything's fine. But
At 05/04/2017 10:04 PM, Anand Jain wrote:
Hi Qu,
The commit 81fb6f77a026 (btrfs: qgroup: Add new trace point for
qgroup data reserve) added the following events which aren't used.
btrfs__qgroup_data_map
btrfs_qgroup_init_data_rsv_map
btrfs_qgroup_free_data_rsv_map
I wonder if it is be
At 05/03/2017 10:21 PM, Christophe de Dinechin wrote:
On 2 May 2017, at 02:17, Qu Wenruo wrote:
At 04/28/2017 04:47 PM, Christophe de Dinechin wrote:
On 28 Apr 2017, at 02:45, Qu Wenruo wrote:
At 04/26/2017 01:50 AM, Christophe de Dinechin wrote:
Hi,
I”ve been trying to run btrfs as
Hello!
Since I saw a few kernel freezes lately (due to experimenting with
ck-sources) including some filesystem-related backtraces, I booted my
rescue system to check my btrfs filesystem.
Luckily, it showed no problems. It said, everything's fine. But I also
thought: Okay, let's try lowmem mode.
On Sun, Apr 23, 2017 at 01:12:42PM +0530, Lakshmipathi.G wrote:
> Thanks for the example and details. I understood some and need to
> re-read couple of more times to understand the remaining.
>
> btw, I created a corruption framework(with previous org), the sample
> usage and example is below. It
Matt McKinnon posted on Thu, 04 May 2017 09:15:28 -0400 as excerpted:
> Hi All,
>
> Trying to peg down why I have one server that has btrfs-transacti pegged
> at 100% CPU for most of the time.
>
> I thought this might have to do with fragmentation as mentioned in the
> Gotchas page in the wiki (
> Trying to peg down why I have one server that has
> btrfs-transacti pegged at 100% CPU for most of the time.
Too little information. Is IO happening at the same time? Is
compression on? Deduplicated? Lots of subvolumes? SSD? What kind
of workload and file size/distribution profile?
Typical high
Hi Qu,
The commit 81fb6f77a026 (btrfs: qgroup: Add new trace point for
qgroup data reserve) added the following events which aren't used.
btrfs__qgroup_data_map
btrfs_qgroup_init_data_rsv_map
btrfs_qgroup_free_data_rsv_map
I wonder if it is better to remove or keep it for future use.
Signed
Hi All,
Trying to peg down why I have one server that has btrfs-transacti pegged
at 100% CPU for most of the time.
I thought this might have to do with fragmentation as mentioned in the
Gotchas page in the wiki (btrfs-endio-wri doesn't seem to be involved as
mentioned in the wiki), but after
> On 3 May 2017, at 16:21, Christophe de Dinechin wrote:
>
>>
>> On 2 May 2017, at 02:17, Qu Wenruo wrote:
>>
>>
>>
>> At 04/28/2017 04:47 PM, Christophe de Dinechin wrote:
On 28 Apr 2017, at 02:45, Qu Wenruo wrote:
At 04/26/2017 01:50 AM, Christophe de Dinechin
I've been working on set of patches to clean up how writeback errors are
tracked and handled in the kernel:
http://marc.info/?l=linux-fsdevel&m=149304074111261&w=2
The basic idea is that rather than having a set of flags that are
cleared whenever they are checked, we have a sequence counter and e
17 matches
Mail list logo
