OK I do finally get a message indicating a blocked task so I've updated the
file, and also decided to just file a kernel bug on it so the file is assured
to be somewhere more permanent.
https://bugzilla.kernel.org/show_bug.cgi?id=75271
Chris Murphy--
To unsubscribe from this list: send the lin
btrfs device add hang is reproduced with 3.15.0-0.rc3.git3.1.fc21.x86_64 which
has some debugging options enabled; although btrfs options are the same as the
non-debug kernel. There is slightly more information in the stack traces
however.
# grep -i btrfs config-3.15.0-0.rc3.git3.1.fc21.x86_64
I had 3 x 3 TB drives in an almost full btrfs raid1 setup containing
only large (~20 GB) files linearly written and not modified after.
Then one of the drives got busted.
> Mounting the fs in degraded mode
and adding a new fresh drive to rebuild raid1, generated several
"...blocked for more t
On Thu, 1 May 2014, Chris Murphy wrote:
> That has not been my experience. I changed /boot files to have the wrong
> selinux labels, set .autorelabel, rebooted, and those files were fixed
> despite /boot being a mount point for a btrfs subvolume named boot located
> at the top level of the file sy
On Thu, 1 May 2014, Duncan <1i5t5.dun...@cox.net> wrote:
> That's why I'm running raid1 for both data and metadata here. I love
> btrfs' data/metadata checksumming and integrity mechanisms, and having
> that second copy to scrub from in the event of an error on one of them is
> just as important t
>On 27/04/14 13:00, Пламен Петров wrote:
>> The problem reported in this thread has been RESOLVED.
>>
>> It's not BTRFS's fault.
>>
>> Debugging on my part led to the actual problem in do_mounts.c - some
>> filesystems mount routines return error codes other than 0, EACCES
>> and EINVAL and such
Dear all,
I have very high load when writing/reading from/to two of my btrfs
volumes. One sda1, mounted as /mnt/BTRFS, the other, sdd2/sde2 (raid) as /
sda1 is a 3TB disc, whereas the sdd2/sde2 are small SSDs of 16GB.
I wrote a small script to demonstrate it. It does:
-echo what it will do
-s
Neuer User posted on Thu, 01 May 2014 10:14:35 +0200 as excerpted:
> It's probably best to copy al my data to another disk, then delete the
> parttiion and make a new ext4 partition. btrfs is probably still too
> experimental, I guess.
I thought I replied to this one but it was to a different, si
Alin Dobre posted on Thu, 01 May 2014 14:32:55 +0100 as excerpted:
> I am having trouble with one of the btrfs subvolumes, as it shows
> negative quota accounting values
> Running a "btrfs quota rescan -w /tmp/test" seems to fix it, but it
> seems to come back pretty often (happened twice in the
On 05/01/2014 12:16 AM, Jan Kasiak wrote:
Is there a design/technical reason behind btrfs using checksums
separately per block, versus checksumming into a merkle tree?
We're using crc32c, which isn't suitable for detecting malicious data in
general. The goal was just to find blocks that were
Hello,
I am having trouble with one of the btrfs subvolumes, as it shows
negative quota accounting values, like in the following output:
# btrfs qgroup show -f /tmp/test
qgroupid rfer excl
0/299-1576960 -1511424
Running a
On 2014-04-30 14:16, Felix Homann wrote:
> Hi,
> a couple of months ago there has been some discussion about issues
> when using btrfs on bcache:
>
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/31018
>
> From looking at the mailing list archives I cannot tell whether or not
> this issue
It's probably best to copy al my data to another disk, then delete the
parttiion and make a new ext4 partition. btrfs is probably still too
experimental, I guess.
Am 30.04.2014 08:37, schrieb Neuer User:
> Hi
>
> I have a non-rootfs btrfs partition that I use for some work where I
> like to keep
13 matches
Mail list logo
