We've got bug reports that btrfs crashes when quota is enabled on
32bit kernel, typically with the Oops like below:
BUG: unable to handle kernel NULL pointer dereference at 0004
IP: [f9234590] find_parent_nodes+0x360/0x1380 [btrfs]
*pde =
Oops: [#1] SMP
CPU: 0 PID: 151 Comm:
Hi Takashi,
This seems like a promising fix, i just have a little question:
ulist_add() logic is we firstly cast a pointer to u64(see ptr_to_u64()),
and then
cast u64 to pointer back(u64_to_ptr()). So normally, arg u64 is actually
a pointer.
If the below overflow happens, that means casting
At Mon, 28 Jul 2014 17:38:52 +0800,
Wang Shilong wrote:
Hi Takashi,
This seems like a promising fix, i just have a little question:
ulist_add() logic is we firstly cast a pointer to u64(see ptr_to_u64()),
and then
cast u64 to pointer back(u64_to_ptr()). So normally, arg u64 is actually
On Fri, Jul 25, 2014 at 01:37:10PM +0200, Torbjørn wrote:
On 25. juli 2014 13:09, Torbjørn wrote:
On 25. juli 2014 12:22, Torbjørn wrote:
On 25. juli 2014 11:28, Liu Bo wrote:
Hi Torbjørn,
On Fri, Jul 25, 2014 at 06:51:44AM +0200, Torbjørn wrote:
On 07/24/2014 04:58 PM, Chris Mason wrote:
On Sun, Jul 27, 2014 at 11:21:53PM -0400, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 04:47 PM, Nick Krause wrote:
This may be a bad idea , but compression in brtfs seems to be only
using one core to compress.
On Mon, Jul 28, 2014 at 12:00:03AM -0400, Nick Krause wrote:
Hey Josef,
Seems there are a lot of brtfs bugs open on the kernel Bugzilla. I am
new to the brtfs
side of development so please let me known if you want help cleaning
up some of the
bugs here that are actually valid and still open.
On 07/27/2014 11:21 PM, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 04:47 PM, Nick Krause wrote:
This may be a bad idea , but compression in brtfs seems to be only
using one core to compress.
Depending on the CPU used and
On 28. juli 2014 12:00, Liu Bo wrote:
snip
This seems to be incomplete(Looks like dmesg has reached its buffer size limit),
does /var/log/message have the whole stack info?
thanks,
-liubo
Hi,
Complete log was over 40MB. I uploaded everything from boot until
blocked for 120 seconds started to
Hugo,
On Fri, Jul 25, 2014 at 10:13:11AM +0100, Hugo Mills wrote:
[this time, to the mailing list as well]
thank you for the writeup, I've put it on the wiki (Deverloper's FAQ) to
give an idea how to start with the development.
--
To unsubscribe from this list: send the line unsubscribe
small wording error inline below
Date: Fri, 25 Jul 2014 15:17:05 +0900
From: takeuchi_sat...@jp.fujitsu.com
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 2/2] btrfs-progs: Unify the messy error message formats
From: Satoru Takeuchi
On 07/28/2014 04:57 AM, Takashi Iwai wrote:
We've got bug reports that btrfs crashes when quota is enabled on
32bit kernel, typically with the Oops like below:
BUG: unable to handle kernel NULL pointer dereference at 0004
IP: [f9234590] find_parent_nodes+0x360/0x1380 [btrfs]
*pde =
At Mon, 28 Jul 2014 09:16:48 -0400,
Josef Bacik wrote:
On 07/28/2014 04:57 AM, Takashi Iwai wrote:
We've got bug reports that btrfs crashes when quota is enabled on
32bit kernel, typically with the Oops like below:
BUG: unable to handle kernel NULL pointer dereference at 0004
At Mon, 28 Jul 2014 15:48:41 +0200,
Takashi Iwai wrote:
At Mon, 28 Jul 2014 09:16:48 -0400,
Josef Bacik wrote:
On 07/28/2014 04:57 AM, Takashi Iwai wrote:
We've got bug reports that btrfs crashes when quota is enabled on
32bit kernel, typically with the Oops like below:
BUG:
On Mon, Jul 28, 2014 at 6:10 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 11:21 PM, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 04:47 PM, Nick Krause wrote:
This may be a bad idea , but compression in
On Mon, Jul 28, 2014 at 6:09 AM, Hugo Mills h...@carfax.org.uk wrote:
On Mon, Jul 28, 2014 at 12:00:03AM -0400, Nick Krause wrote:
Hey Josef,
Seems there are a lot of brtfs bugs open on the kernel Bugzilla. I am
new to the brtfs
side of development so please let me known if you want help
On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause xerofo...@gmail.com wrote:
On Mon, Jul 28, 2014 at 6:10 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 11:21 PM, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014
On 2014-07-28 11:57, Nick Krause wrote:
On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Jul 28, 2014 at 6:10 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014 11:21 PM, Nick Krause wrote:
On Sun, Jul 27, 2014 at 10:56 PM, Austin S Hemmelgarn
Thanks for the feedback.
On Thu, Jul 24, 2014 at 04:34:35PM -0600, Andreas Dilger wrote:
- rename fe_length to fe_logi_length and #define fe_length fe_logi_length
- always fill in fe_phys_length (= fe_logi_length for uncompressed files)
and set FIEMAP_EXTENT_PHYS_LENGTH whether the extent
On Sat, Jun 28, 2014 at 12:34 PM, Miao Xie mi...@cn.fujitsu.com wrote:
The current code would load checksum data for several times when we split
a whole direct read io because of the limit of the raid stripe, it would
make us search the csum tree for several times. In fact, it just wasted time,
This is a better solution for the problem addressed in the following
commit:
Btrfs: update commit root on snapshot creation after orphan cleanup
(3821f348889e506efbd268cc8149e0ebfa47c4e5)
The previous solution wasn't the best because of 2 reasons:
1) It added another full
On Sat, Jul 19, 2014 at 8:11 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi Filipe,
It's quite possible I don't fully understand the issue. It seems that
we are creating a read-only snapshot, commit a transaction, and then
go and modify the snapshot once again, by deleting all the
In ctree.c:setup_items_for_insert(), we can unlock all nodes in our
path before we process the leaf (shift items and data, adjust data
offsets, etc). This allows for better btree concurrency, as we're
often holding a write lock on at least the node at level 1.
Signed-off-by: Filipe Manana
If we need to cow a node, increase the write lock level and retry the
tree search, there's no point of changing the node locks in our path
to blocking mode, as we only waste time and unnecessarily wake up other
tasks waiting on the spinning locks (just to block them again shortly
after) because we
On Mon, Jul 28, 2014 at 12:19 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 2014-07-28 11:57, Nick Krause wrote:
On Mon, Jul 28, 2014 at 11:13 AM, Nick Krause xerofo...@gmail.com
wrote:
On Mon, Jul 28, 2014 at 6:10 AM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
On 07/27/2014
Hi together,
In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of
https://github.com/kdave/btrfs-progs.git (I assume this list is the
right address because I got some hints to the project from here) the
btrfs restore subcommand asks often (up to 100 time during restauration
of 400 GB)
Am Donnerstag, 24. Juli 2014, 16:04:22 schrieb Chris Mason:
On 07/24/2014 02:49 PM, Martin Steigerwald wrote:
Am Donnerstag, 24. Juli 2014, 10:58:51 schrieb Chris Mason:
On 07/23/2014 06:47 PM, Martin Steigerwald wrote:
Am Dienstag, 15. Juli 2014, 17:08:27 schrieb Martin Steigerwald:
Am
If you are using btrfs restore to try to recover a very large or
fragmented file, you may encounter _lots_ of prompts requiring
you to press 'y' to continue because we are looping a lot.
Add the option to press 'a', to supress these prompts for the rest
of the file.
---
cmds-restore.c | 17
On Mon, Jul 28, 2014 at 3:35 PM, Karl-Philipp Richter
krich...@posteo.de wrote:
Hi together,
In the current HEAD (3f11e516db629f7a662bfd6376231817b4e34cc9) of
https://github.com/kdave/btrfs-progs.git (I assume this list is the
right address because I got some hints to the project from here)
Hi Justin,
thanks for your help. I guess the patch will be available in the repos,
soon, so I'll work with `yes` in the meantime because I'm not too
familiar with patching in this form.
Best regards,
Karl-P. Richter
Am 29.07.2014 um 02:09 schrieb Justin Maggard:
On Mon, Jul 28, 2014 at 3:35 PM,
Hi Justin,
Thanks for the patch first, comment inlined below.
Original Message
Subject: [PATCH] btrfs-progs: add always option to restore's looping prompt
From: Justin Maggard jmaggar...@gmail.com
To: linux-btrfs@vger.kernel.org
Date: 2014年07月29日 08:03
If you are using btrfs
On Mon, 28 Jul 2014 18:24:47 +0100, Filipe David Manana wrote:
On Sat, Jun 28, 2014 at 12:34 PM, Miao Xie mi...@cn.fujitsu.com wrote:
The current code would load checksum data for several times when we split
a whole direct read io because of the limit of the raid stripe, it would
make us
If you are using btrfs restore to try to recover a very large or
fragmented file, you may encounter _lots_ of prompts requiring
you to press 'y' to continue because we are looping a lot.
Add the option to press 'a', to supress these prompts for the rest
of the file.
Signed-off-by: Justin Maggard
Original Message
Subject: [PATCH v2] btrfs-progs: add always option to restore's looping
prompt
From: Justin Maggard jmaggar...@gmail.com
To: linux-btrfs@vger.kernel.org
Date: 2014年07月29日 09:55
If you are using btrfs restore to try to recover a very large or
fragmented file,
Hi Kyle,
(2014/07/28 22:24), Kyle Gates wrote:
small wording error inline below
Date: Fri, 25 Jul 2014 15:17:05 +0900
From: takeuchi_sat...@jp.fujitsu.com
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 2/2] btrfs-progs: Unify the messy error message
Hi Qu,
(2014/07/25 17:16), Qu Wenruo wrote:
Original Message
Subject: Re: [PATCH v2] btrfs: Return right extent when fiemap gives unaligned
offset and len.
From: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com
To: Qu Wenruo quwen...@cn.fujitsu.com, linux-btrfs@vger.kernel.org
35 matches
Mail list logo
