Hi Miao,
On Mon, Mar 25, 2013 at 3:51 AM, Miao Xie wrote:
> On Sun, 24 Mar 2013 13:13:22 +0200, Alex Lyakas wrote:
>> Hi Miao,
>> I am seeing another issue. Your fix prevents from TRANS_START to get
>> in the way of a committing transaction. But it does not prevent from
>> TRANS_JOIN. On the othe
From: Wang Shilong
The function btrfs_find_all_roots is responsible to allocate
memory for 'roots' and free it if errors happen,so the caller should not
free it again since the work has been done.
Besides,'tmp' is allocated after the function btrfs_find_all_roots,
so we can return directly if bt
From: Wang Shilong
The reason that BUG_ON() happens in these places is just
because of ENOMEM.
We try ro return ENOMEM rather than trigger BUG_ON(), the
caller will abort the transaction thus avoiding the kernel panic.
Signed-off-by: Wang Shilong
Reviewed-by: Miao Xie
---
fs/btrfs/backref.c
On Mon, March 25, 2013 at 12:09 (+0100), Wang Shilong wrote:
> From: Wang Shilong
>
> The reason that BUG_ON() happens in these places is just
> because of ENOMEM.
>
> We try ro return ENOMEM rather than trigger BUG_ON(), the
> caller will abort the transaction thus avoiding the kernel panic.
On Mon, March 25, 2013 at 12:08 (+0100), Wang Shilong wrote:
> From: Wang Shilong
>
> The function btrfs_find_all_roots is responsible to allocate
> memory for 'roots' and free it if errors happen,so the caller should not
> free it again since the work has been done.
>
> Besides,'tmp' is alloca
From: Wang Shilong
The reason that BUG_ON() happens in these places is just
because of ENOMEM.
We try ro return ENOMEM rather than trigger BUG_ON(), the
caller will abort the transaction thus avoiding the kernel panic.
Signed-off-by: Wang Shilong
Reviewed-by: Miao Xie
Reviewed-by: Jan Schmidt
Hello,
>
> On Mon, March 25, 2013 at 12:09 (+0100), Wang Shilong wrote:
>> From: Wang Shilong
>>
>> The reason that BUG_ON() happens in these places is just
>> because of ENOMEM.
>>
>> We try ro return ENOMEM rather than trigger BUG_ON(), the
>> caller will abort the transaction thus avoiding
The function pointer bi_end_io expects three arguments of the
function it points to. This patch adds a struct batch_complete
pointer as a third argument to the raid_write_end_io,
raid_rmw_end_io and raid_recover_end_io functions.
GCC is warning about this:
fs/btrfs/raid56.c: In function ‘finish_rm
On 03/21/2013 01:13 AM, Wang Sheng-Hui wrote:
_require_nobigloopfs has been removed.
We should use _require_no_large_scratch_dev in the test script.
Signed-off-by: Wang Sheng-Hui
---
276 |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/276 b/276
index 40b30cf..87363ca
On Sat, Mar 23, 2013 at 04:22:22PM -0600, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 23/03/13 10:48, Eric Sandeen wrote:
> > Btrfs is a new copy on write filesystem for Linux aimed at
>
> How much longer does "new" get to be there as the filesystem has been
> goin
/etc/mtab is not working correctly in situations where multiple
mount namespaces are used. Use /proc/mounts instead like the
rest of the code is doing it.
Signed-off-by: Stefan Behrens
---
cmds-send.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmds-send.c b/cmds-send.c
i
On Sat, Mar 23, 2013 at 06:48:38AM -0300, Alexandre Oliva wrote:
> On Mar 22, 2013, David Sterba wrote:
>
> > I've reproduced this without compression, with autodefrag on.
>
> I don't have autodefrag on, unless it's enabled by default on 3.8.3 or
> on the for-linus tree.
It's not on by default,
On Sat, Mar 23, 2013 at 06:11:26PM -0700, Roger Binns wrote:
> On 23/03/13 15:40, Eric Sandeen wrote:
> > I imagine it depends on the details of the workload & storage as well.
>
> If the people who write btrfs can't come up with some measures to deem
> appropriateness, then how can the administra
Dave reported a warning when running xfstest 275. We have been leaking delalloc
metadata space when our reservations fail. This is because we were improperly
calculating how much space to free for our checksum reservations. The problem
is we would sometimes free up space that had already been fr
On Fri, Mar 22, 2013 at 02:55:07PM -0600, Stefan Priebe wrote:
> Hi Jsoef,
>
> thanks!
Ok I don't think the thing I just fixed will make any difference for you so
here's another debug patch, just apply it on top of what I've already sent you
and re-run and give me the dmesg again. Thanks,
Josef
Quoting Chris Mason (2013-03-22 16:31:42)
> Going through the code here, when I change the test to truncate once in
> the very beginning, I still get errors. So, it isn't an interaction
> between mmap and truncate. It must be a problem between lzo and mmap.
With compression off, we use clear_pag
16 matches
Mail list logo
