Dāvis Mosāns posted on Tue, 14 Jul 2015 04:54:27 +0300 as excerpted:
> 2015-07-13 11:12 GMT+03:00 Duncan <1i5t5.dun...@cox.net>:
>> You say five disk, but nowhere in your post do you mention what raid
>> mode you were using, neither do you post btrfs filesystem show and
>> btrfs filesystem df, as
This reverts commit 5f8232e5c8f0b0de0ef426274911385b0e877392.
This commit causes a regression:
---
$ mkfs.btrfs -f /dev/sda6
$ btrfsck /dev/sda6
Checking filesystem on /dev/sda6
UUID: 2ebb483c-1986-4610-802a-c6f3e6ab4b76
checking extents
Chunk[256, 228, 0]: length(4194304), offset(0), type(2) mism
2015-07-13 11:12 GMT+03:00 Duncan <1i5t5.dun...@cox.net>:
> You say five disk, but nowhere in your post do you mention what raid mode
> you were using, neither do you post btrfs filesystem show and btrfs
> filesystem df, as suggested on the wiki and which list that information.
Sorry, I forgot. I'
Thanks a lot Steve!
With this binary dump, we can find out what's the cause of your problem
and makes btrfsck handle and repair it.
Further more, this provides a good hint on what's going wrong in kernel.
I'll start investigating this right now.
Thanks,
Qu
Steve Dainard wrote on 2015/07/13
On Sun, Jul 12, 2015 at 02:50:47AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Hi Chris,
>
> Please consider the following changes for the kernel 4.2 release. All
> these patches have been available in the mailing list for some time.
>
> One of the patches is a fix for a regress
Hi Qu,
I ran into this issue again, without pacemaker involved, so I'm really
not sure what is triggering this.
There is no content at all on this disk, basically it was created with
a btrfs filesystem, mounted, and now after some reboots later (and
possibly hard resets) won't mount with a stale
Am Mon, 13 Jul 2015 19:21:54 +0200
schrieb Marc Joliet :
> OK, I'll make the changes then (sans kernel log).
Just a heads up: I accepted the terms of service, but the link goes to a
non-existent wiki page.
--
Marc Joliet
--
"People who think they know everything really annoy those of us who kno
Am Mon, 13 Jul 2015 18:30:09 +0200
schrieb David Sterba :
> On Mon, Jul 13, 2015 at 01:18:27PM +0200, Marc Joliet wrote:
> > Am Mon, 13 Jul 2015 06:56:17 + (UTC)
> > schrieb Duncan <1i5t5.dun...@cox.net>:
> >
> > > Marc Joliet posted on Sun, 12 Jul 2015 14:26:04 +0200 as excerpted:
> > >
> >
On Mon, Jul 13, 2015 at 06:55:29PM +0200, Alex Lyakas wrote:
> Filipe,
> Thanks for the explanation. Those reasons were not so obvious for me.
>
> Would it make sense not to COW the block in case-1, if we are mounted
> with "notreelog"? Or, perhaps, to check that the block does not belong
> to a l
Filipe,
Thanks for the explanation. Those reasons were not so obvious for me.
Would it make sense not to COW the block in case-1, if we are mounted
with "notreelog"? Or, perhaps, to check that the block does not belong
to a log tree?
The second case is more difficult. One problem is that
BTRFS_HE
On Mon, Jul 13, 2015 at 01:18:27PM +0200, Marc Joliet wrote:
> Am Mon, 13 Jul 2015 06:56:17 + (UTC)
> schrieb Duncan <1i5t5.dun...@cox.net>:
>
> > Marc Joliet posted on Sun, 12 Jul 2015 14:26:04 +0200 as excerpted:
> >
> > > I hope it's not out of place, but I have a few suggestions for the W
On Jul 12, 2015 at 2026 -0600, Chris Murphy appeared and said:
> On Sun, Jul 12, 2015 at 7:23 PM, René Pfeiffer wrote:
> >...
> > Output of uname, btrfs, and the dmesg log is attached. Let me know if you
> > need anything else. The old Btrfs is still on another disk, and I can
> > extract informat
From: Filipe Manana
Hi Chris,
Please consider the following changes for the kernel 4.2 release. All
these patches have been available in the mailing list for some time.
One of the patches is a fix for a regression in the delayed references
code that landed in 4.2-rc1. Two of them are for issues
Last time something happened and I poked at it myself I ended up
ruining the pool so I thought I'd ask here before doing anything.
I'm not sure if this really indicates that anything needs doing or
not. The filesystem will mount like normal.
It doesn't look like the core dump was written anywher
Am 13.07.2015 um 13:20 schrieb Austin S Hemmelgarn:
> On 2015-07-11 02:46, Stefan Priebe wrote:
>> Hi,
>>
>> while using a 40TB btrfs partition for VM backups. I see a massive
>> slowdown after around one week.
>>
>> The backup task takes usally 2-3 hours. After one week it takes 20
>> hours. If i
Since upgrading to a kernel with the automatic chunk reclamation
patches, I've noticed a number of issues with BTRFS that all seem to
either be caused by, or are further exacerbated by, this 'feature'.
The four big issues I've seen regarding it are:
1. TRIM/DISCARD support is broken as a (parti
On 2015-07-11 11:24, Duncan wrote:
I'm not a coder, only a list regular and btrfs user, and I'm not sure on
this, but there have been several reports of this nature on the list
recently, and I have a theory. Maybe the devs can step in and either
confirm or shoot it down.
While I am a coder, I'm
On 2015-07-11 02:46, Stefan Priebe wrote:
Hi,
while using a 40TB btrfs partition for VM backups. I see a massive
slowdown after around one week.
The backup task takes usally 2-3 hours. After one week it takes 20
hours. If i umount and remount the btrfs volume it takes 2-3 hours again.
Kernel 4
Am Mon, 13 Jul 2015 06:56:17 + (UTC)
schrieb Duncan <1i5t5.dun...@cox.net>:
> Marc Joliet posted on Sun, 12 Jul 2015 14:26:04 +0200 as excerpted:
>
> > I hope it's not out of place, but I have a few suggestions for the Wiki:
>
> Just in case it wasn't obvious... The wiki is open to user edi
On Sun, Jul 12, 2015 at 6:15 PM, Alex Lyakas wrote:
> Greetings,
> Looking at the code of should_cow_block(), I see:
>
> if (btrfs_header_generation(buf) == trans->transid &&
>!btrfs_header_flag(buf, BTRFS_HEADER_FLAG_WRITTEN) &&
> ...
> So if the extent buffer has been written to disk, and no
Dāvis Mosāns posted on Mon, 13 Jul 2015 09:26:05 +0300 as excerpted:
> Short version: while doing scrub on 5 disk btrfs filesystem, /dev/sdd
> "failed" and also had some error on other disk (/dev/sdh)
You say five disk, but nowhere in your post do you mention what raid mode
you were using, neith
On 10 July 2015 at 06:05, None None wrote:
> According to dmesg sda returns bad data but the smart values for it seem fine.
> # smartctl -a /dev/sda
...
> SMART Self-test log structure revision number 1
> No self-tests have been logged. [To run self-tests, use: smartctl -t]
Run smartctl -t long
22 matches
Mail list logo
