Hi,

Filipe David Manana <fdman...@gmail.com> writes:

> On Thu, Aug 21, 2014 at 1:07 PM, Naohiro Aota <na...@elisp.net> wrote:
>> free_some_buffer() should not free dirty extent buffers. They should be
>> left for later commit.
>>
>> Signed-off-by: Naohiro Aota <na...@elisp.net>
>> ---
>>  extent_io.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/extent_io.c b/extent_io.c
>> index a127e54..8a668be 100644
>> --- a/extent_io.c
>> +++ b/extent_io.c
>> @@ -552,7 +552,7 @@ static int free_some_buffers(struct extent_io_tree *tree)
>>
>>         list_for_each_safe(node, next, &tree->lru) {
>>                 eb = list_entry(node, struct extent_buffer, lru);
>> -               if (eb->refs == 1) {
>> +               if (eb->refs == 1 && !(eb->flags && EXTENT_DIRTY)) {
>
> Hi,
>
> Did you meant bitwise and (&) and not logical and (&&) right?

Oops, you're right. Following is the new patch.

>From 0e1a49216d40b44909cdfacd5cd9a13aa796db41 Mon Sep 17 00:00:00 2001
From: Naohiro Aota <na...@elisp.net>
Date: Mon, 25 Aug 2014 14:03:59 +0900
Subject: [PATCH] btrfs-progs: Do not free dirty extent buffer

free_some_buffer() should not free dirty extent buffers. They are left
to be committed.

Signed-off-by: Naohiro Aota <na...@elisp.net>
---
 extent_io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/extent_io.c b/extent_io.c
index a127e54..1df377d 100644
--- a/extent_io.c
+++ b/extent_io.c
@@ -552,7 +552,7 @@ static int free_some_buffers(struct extent_io_tree *tree)
 
        list_for_each_safe(node, next, &tree->lru) {
                eb = list_entry(node, struct extent_buffer, lru);
-               if (eb->refs == 1) {
+               if (eb->refs == 1 && !(eb->flags & EXTENT_DIRTY)) {
                        free_extent_buffer(eb);
                        if (tree->cache_size < cache_hard_max)
                                break;
-- 
2.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to