On Sun, May 28, 2017 at 6:56 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> [This mail was also posted to gmane.comp.file-systems.btrfs.]
>
> Ivan P posted on Sat, 27 May 2017 22:54:31 +0200 as excerpted:
>
>>>>>> Please add me to CC when replying, as I am not
&
On Sat, May 27, 2017 at 10:42 PM, Hans van Kranenburg
wrote:
> On 05/27/2017 10:29 PM, Ivan P wrote:
>> On Sat, May 27, 2017 at 9:33 PM, Hans van Kranenburg
>> wrote:
>>> Hi,
>>>
>>> On 05/27/2017 08:53 PM, Ivan P wrote:
>>>>
>>>
On Sat, May 27, 2017 at 9:33 PM, Hans van Kranenburg
wrote:
> Hi,
>
> On 05/27/2017 08:53 PM, Ivan P wrote:
>>
>> for a while now, btrfs-cleaner has been molesting my system's btrfs
>> partition,
>> as well as my CPU. The behavior is as following:
&g
Hello,
for a while now, btrfs-cleaner has been molesting my system's btrfs partition,
as well as my CPU. The behavior is as following:
After booting, nothing relevant is happening. After about 5-30 minutes,
a btrfs-cleaner process is spawned, which is constantly using one CPU core.
The btrfs-clea
sion.
Regards,
Ivan.
On Fri, May 20, 2016 at 2:44 AM, Qu Wenruo wrote:
>
>
> Ivan P wrote on 2016/05/19 18:54 +0200:
>>
>> Not sure why I was so fixated on installing it - thanks for reminding.
>>
>> I was able to run it, but it fails:
>> ===
t you don't really need to install the
> patch.
>
> You can just execute '/btrfsck' directly to
> call the new fsck.
>
> And there is still some time before the patch is merged, there is really no
> need to install.
>
> Thanks,
> Qu
>
>
> Ivan
ue, May 17, 2016 at 5:56 AM, Qu Wenruo wrote:
> Also to Ivan P, the initial reporter of the problem.
>
> Now "btrfsck --clear-cache" should help you to prevent kernel warning on
> free space cache problem.
>
> Thanks,
> Qu
>
> Qu Wenruo wrote on 2016/05/17 11:47 +
Issue persists with btrfs-progs 4.5.1 and linux 4.5.1.
Did you have time to implement that option in btrfsck you were talking about?
I'm a bit reluctant to use this partition at this point.
Regards
Ivan
On Tue, Apr 12, 2016 at 7:15 PM, Ivan P wrote:
> Feel free to send me that modified
cache in case
> kernel mount option doesn't work, and hopes it may help you.
>
> Thanks,
> Qu
>
>
> Ivan P wrote on 2016/04/09 11:53 +0200:
>>
>> Well, the message is almost the same after mounting with clear_cach
, then that's maybe it.
On Fri, Apr 8, 2016 at 2:23 AM, Qu Wenruo wrote:
>
>
> Ivan P wrote on 2016/04/07 17:33 +0200:
>>
>> After running btrfsck --readonly again, the output is:
>>
>> ===
>> Checking filesystem on /dev/sdb
: 858788433920
referenced 858787872768
===
Seems the free space is wrong because more data blocks are allocated
than referenced?
Regards,
Ivan.
On Thu, Apr 7, 2016 at 2:58 AM, Qu Wenruo wrote:
>
>
> Ivan P wrote on 2016/04/06 21:39 +0200:
>>
>&g
30332/image.btrfs (821Mb)
Maybe you will be able to track down whatever caused this.
Regards,
Ivan.
On Sun, Apr 3, 2016 at 3:24 AM, Qu Wenruo wrote:
>
>
> On 04/03/2016 12:29 AM, Ivan P wrote:
>>
>> It's about 800Mb, I think I could upload that.
>>
>> I ran it with
It's about 800Mb, I think I could upload that.
I ran it with the -s parameter, is that enough to remove all personal
info from the image?
Also, I had to run it with -w because otherwise it died on the same
corrupt node.
On Fri, Apr 1, 2016 at 2:25 AM, Qu Wenruo wrote:
>
>
> Ivan P
repair?
Regards,
Ivan
On Mon, Mar 28, 2016 at 3:10 AM, Qu Wenruo wrote:
>
>
> Ivan P wrote on 2016/03/27 16:31 +0200:
>>
>> Thanks for the reply,
>>
>> the raid1 array was created from scratch, so not converted from ext*.
>> I used btrfs-progs version 4.2.3 o
..forgot to paste btrfs-version: 4.4.1
(slightly outdated, but it's the current version on arch linux)
On Sun, Mar 27, 2016 at 11:54 AM, Ivan P wrote:
> Read the info on the wiki, here's the rest of the requested information:
>
> # uname -r
> 4.4.5-1-ARCH
>
> # btrfs
iB, used=799.81GiB
System, RAID1: total=8.00MiB, used=128.00KiB
Metadata, RAID1: total=2.00GiB, used=936.20MiB
GlobalReserve, single: total=320.00MiB, used=0.00B
On Fri, Mar 25, 2016 at 3:16 PM, Ivan P wrote:
> Hello,
>
> using kernel 4.4.5 and btrfs-progs 4.4.1, I today ran a scrub on m
Hello,
using kernel 4.4.5 and btrfs-progs 4.4.1, I today ran a scrub on my
2x1Tb btrfs raid1 array and it finished with 36 unrecoverable errors
[1], all blaming the treeblock 741942071296. Running "btrfs check
--readonly" on one of the devices lists that extent as corrupted [2].
How can I recove
17 matches
Mail list logo
