On Wed, 23 Oct 2013 13:28:44 +0900
Tomasz Chmielewski wrote:
OK, putting high load aside - it finished, with no errors:
# btrfs scrub status /mnt/lxc1
scrub status for 8d08ad6d-4543-4fe5-8b1b-640dc1423d41
scrub started at Wed Oct 23 04:19:55 2013 and finished after 68479
seconds
This has been committed.
Thanks
--Rich
commit 5b8e9ac03259a11de8fd84d939f25a2cbbafab18
Author: Eryu Guan
Date: Wed Oct 23 16:44:43 2013 +
xfstests btrfs/020: test device replace on RO btrfs
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a mes
Hi,
I have a btrfs filesystem on a USB stick. A few days ago, my cell phone was
right next to the stick while both (teh stick and the phone) were in use. I
suppose the irradiation from the phone must have interacted badly with the
stick. The syslog showed some messages from the btrfs modules c
OK. btrfs scrub and dmesg is hitting me with lots of unfixable errors.
All in the same file. Example
[13313.441091] btrfs: unable to fixup (regular) error at logical
560107954176 on dev /dev/sdn
[13321.532223] scrub_handle_errored_block: 1510 callbacks suppressed
[13321.532309] btrfs_dev_stat_prin
On Wed, Oct 23, 2013 at 12:45:07PM -0500, Eric Sandeen wrote:
> On 10/23/13 12:05 PM, Stefan Behrens wrote:
> > On Thu, 24 Oct 2013 00:44:43 +0800, Eryu Guan wrote:
> >> +# real QA test starts here
> >> +_supported_fs btrfs
> >> +_supported_os Linux
> >
> > It is still unclear to me why everybody
I was hit by this when trying to rebalance a 16TB RAID10 to 32TB
RAID10 going from 4 to 8 WD SE 4TB drives today. I cannot finish a
rebalance because of failed csum.
[10228.850910] BTRFS info (device sdq): csum failed ino 487 off 65536
csum 2566472073 private 151366068
[10228.850967] BTRFS info (d
In some cases the tree root is so hosed we can't get anything useful out of it.
So add the -b option to btrfsck to make us look for the most recent backup tree
root to use for repair. Then we can hopefully get ourselves into a working
state. Thanks,
Signed-off-by: Josef Bacik
---
btrfs-debug-t
Sean Clarke posted on Wed, 23 Oct 2013 20:26:15 +0100 as excerpted:
> I have looked in bugzilla and can't relate this to anything already
> reported, has anyone seen something similar to this?
I don't do NFS so didn't pay attention to the details, but look here on-
list as IIRC there was a very s
Hi,
I have an Intel Core i7 based fileserver with 18TB BTRFS in a 6x
3TB RAID 1+0 configuration. The system was working fine running Ubuntu
13.04 (kernel 3.11.0-12-generic). The system was upgraded to Ubuntu
13.10 (kernel 3.11) and began to lock up daily, sometimes every couple
of hours. Previou
On 23/10/13 17:21, Josef Bacik wrote:
> On Wed, Oct 23, 2013 at 04:32:51PM +0100, Martin wrote:
>>
>> Any further debug useful?
>>
>
> Nope I know where it's breaking, I need to fix how we init the extent tree.
> Thanks,
Good stuff.
If of help, I can test new code or a patch for that example. (
On 10/23/13 11:44 AM, Eryu Guan wrote:
> btrfs replace on readonly fs should not be allowed.
>
> Regression test case for commit:
> bbb651e Btrfs: don't allow the replace procedure on read only filesystems
>
> Signed-off-by: Eryu Guan
Reviewed-by: Eric Sandeen
> ---
> v2: Address Eric's revie
On 10/23/13 12:05 PM, Stefan Behrens wrote:
> On Thu, 24 Oct 2013 00:44:43 +0800, Eryu Guan wrote:
>> btrfs replace on readonly fs should not be allowed.
>>
>> Regression test case for commit:
>> bbb651e Btrfs: don't allow the replace procedure on read only filesystems
>>
>> Signed-off-by: Eryu Gua
On Tue, 22 Oct 2013 18:55:59 +0200, Bob Marley wrote:
> On 22/10/2013 10:37, Stefan Behrens wrote:
>> I don't believe that this issue can ever happen. I don't believe that
>> somewhere on the path to the flash memory, to the magnetic disc or to
>> the drive's cache memory, someone interrupts a 4KB
On Thu, 24 Oct 2013 00:44:43 +0800, Eryu Guan wrote:
> btrfs replace on readonly fs should not be allowed.
>
> Regression test case for commit:
> bbb651e Btrfs: don't allow the replace procedure on read only filesystems
>
> Signed-off-by: Eryu Guan
> ---
> v2: Address Eric's review
> - use trun
New option to subvolume list that acts as a global filter and applies
the other filters to either live subvolumes or the uncleaned ones.
The path to the deleted subvolumes is lost at the deletion time, sample
output looks like:
ID 259 gen 7 top level 0 path /DELETED
Signed-off-by: David Sterba
btrfs replace on readonly fs should not be allowed.
Regression test case for commit:
bbb651e Btrfs: don't allow the replace procedure on read only filesystems
Signed-off-by: Eryu Guan
---
v2: Address Eric's review
- use truncate to create fs image instead of writing to each file
tests/btrfs/0
On Wed, Oct 23, 2013 at 11:25:50AM -0500, Eric Sandeen wrote:
> On 10/23/13 6:24 AM, Eryu Guan wrote:
> > btrfs replace on readonly fs should not be allowed.
> >
> > Regression test case for commit:
> > bbb651e Btrfs: don't allow the replace procedure on read only filesystems
> >
> > Signed-off-b
We were bug_on(slot == 0), but that's just obnoxious, return -ENOENT so we can
handle the situation properly. Thanks,
Signed-off-by: Josef Bacik
---
root-tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/root-tree.c b/root-tree.c
index bdc8504..858fe2f 100644
--- a/ro
On 10/23/13 6:24 AM, Eryu Guan wrote:
> btrfs replace on readonly fs should not be allowed.
>
> Regression test case for commit:
> bbb651e Btrfs: don't allow the replace procedure on read only filesystems
>
> Signed-off-by: Eryu Guan
Could you speed this up by just truncating the loop files to
On Wed, Oct 23, 2013 at 04:32:51PM +0100, Martin wrote:
> On 22/10/13 19:17, Josef Bacik wrote:
> > On Tue, Oct 22, 2013 at 06:58:48PM +0100, Martin wrote:
> >> Dear list,
> >>
> >> I've been trying to recover a 2TB single disk btrfs from a good few days
> >> ago as already commented on the list. b
On Oct 22, 2013, at 9:58 PM, Henry de Valence wrote:
>
>
> btrfs: bdev /dev/bcache0 errs: wr 0, rd 0, flush 0, corrupt 16, gen 0
>
> but when I run btrfs scrub I get:
>
> scrub status for 56118d27-c9a8-483c-afaa-e429d59884e9
> scrub started at Tue Oct 22 22:46:17 2013 and finished after 2
On 22/10/13 19:17, Josef Bacik wrote:
> On Tue, Oct 22, 2013 at 06:58:48PM +0100, Martin wrote:
>> Dear list,
>>
>> I've been trying to recover a 2TB single disk btrfs from a good few days
>> ago as already commented on the list. btrfsck complained of an error in
>> the extents and so I tried:
>>
>
On Wed, Oct 23, 2013 at 3:14 PM, Alex Lyakas
wrote:
> Hello,
>
> On Wed, Oct 23, 2013 at 4:35 PM, Filipe David Manana
> wrote:
>> On Wed, Oct 23, 2013 at 2:33 PM, Alex Lyakas
>> wrote:
>>> Hi Filipe,
>>>
>>>
>>> On Tue, Aug 20, 2013 at 2:52 AM, Filipe David Borba Manana
>>> wrote:
Th
Hello,
On Wed, Oct 23, 2013 at 4:35 PM, Filipe David Manana wrote:
> On Wed, Oct 23, 2013 at 2:33 PM, Alex Lyakas
> wrote:
>> Hi Filipe,
>>
>>
>> On Tue, Aug 20, 2013 at 2:52 AM, Filipe David Borba Manana
>> wrote:
>>>
>>> This issue is simple to reproduce and observe if kmemleak is enabled.
>>
On Wed, Oct 23, 2013 at 2:33 PM, Alex Lyakas
wrote:
> Hi Filipe,
>
>
> On Tue, Aug 20, 2013 at 2:52 AM, Filipe David Borba Manana
> wrote:
>>
>> This issue is simple to reproduce and observe if kmemleak is enabled.
>> Two simple ways to reproduce it:
>>
>> ** 1
>>
>> $ mkfs.btrfs -f /dev/loop0
>>
Hi Filipe,
On Tue, Aug 20, 2013 at 2:52 AM, Filipe David Borba Manana
wrote:
>
> This issue is simple to reproduce and observe if kmemleak is enabled.
> Two simple ways to reproduce it:
>
> ** 1
>
> $ mkfs.btrfs -f /dev/loop0
> $ mount /dev/loop0 /mnt/btrfs
> $ btrfs balance start /mnt/btrfs
> $
Henry de Valence posted on Tue, 22 Oct 2013 23:58:33 -0400 as excerpted:
> Second, I’m having some intermittent data corruption issues, and I’m not
> really sure how to pin down the cause. Sometimes, I’ll get errors trying
> to read a file due to a failed checksum, but when I run btrfs scrub, it
>
On 10/23/13 12:52 AM, David Sterba wrote:
On Tue, Oct 22, 2013 at 09:21:47AM -0400, Josef Bacik wrote:
Did you test these? Because they aren't working for me, so I think a
revert is
the only solution. Thanks,
The impact of the failing test is imho not that big to justify a full
revert fro
btrfs replace on readonly fs should not be allowed.
Regression test case for commit:
bbb651e Btrfs: don't allow the replace procedure on read only filesystems
Signed-off-by: Eryu Guan
---
tests/btrfs/020 | 84 +
tests/btrfs/020.out | 2 ++
On 10/23/13 12:52 AM, David Sterba wrote:
On Tue, Oct 22, 2013 at 09:21:47AM -0400, Josef Bacik wrote:
Did you test these? Because they aren't working for me, so I think a revert is
the only solution. Thanks,
The impact of the failing test is imho not that big to justify a full
revert from
When I try to umount btrfs filesystem I get always this error with
kernel 3.11.4 and 3.11.3, but I can mount and umount without error on
kernel 3.11.2.
Exact error messages are:
BUG: soft lockup - CPU#0 stuck for 23s! [btrfs-transacti:680]
BUG: soft lockup - CPU#1 stuck for 23s! [umount:1575]
31 matches
Mail list logo
