Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josef Bacik <josef@redhat.com>,
	Chris Mason <chris.mason@oracle.com>,
	stable@vger.kernel.org, linux-btrfs@vger.kernel.org,
	ceph-devel@vger.kernel.org
Subject: ceph-on-btrfs inline-cow regression fix for 3.4.3
Date: Wed, 13 Jun 2012 00:46:26 -0300	[thread overview]
Message-ID: <orvcivvppp.fsf@livre.localdomain> (raw)

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Hi, Greg,

There's a btrfs regression in 3.4 that's causing a lot of grief to
ceph-on-btrfs users like myself.  This small and nice patch cures it.
It's in Linus' master already.  I've been running it on top of 3.4.2,
and it would be very convenient for me if this could be in 3.4.3.

Although the patch mentions ENOSPC, the fix has nothing to do with disk
full conditions; it's more along the lines of not finding enough room
for inline data contents and/or failing to split the btree nodes to make
room for it.  I don't know that anyone knows for sure, but without this
patch what we get is a horrible error, that can only be fixed with a
reboot.  Yeah, not even umount&&mount will make the filesystem writable
again.  The fix makes us return an error condition in this case, that
callers are prepared to deal with.

I know btrfs hasn't had maintenance fixes in stable series, but Chris
Mason tells me the only reason is that nobody stepped up to do so.
Given my interest, I might as well give it a try ;-)

Thanks,


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Btrfs-fall-back-to-non-inline-if-we-don-t-have-enoug.patch --]
[-- Type: text/x-diff, Size: 1282 bytes --]

>From 2adcac1a7331d93a17285804819caa96070b231f Mon Sep 17 00:00:00 2001
From: Josef Bacik <josef@redhat.com>
Date: Wed, 23 May 2012 16:10:14 -0400
Subject: [PATCH] Btrfs: fall back to non-inline if we don't have enough space

If cow_file_range_inline fails with ENOSPC we abort the transaction which
isn't very nice.  This really shouldn't be happening anyways but there's no
sense in making it a horrible error when we can easily just go allocate
normal data space for this stuff.  Thanks,

Signed-off-by: Josef Bacik <josef@redhat.com>
---
 fs/btrfs/inode.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 0298928..92df0a5 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -257,10 +257,13 @@ static noinline int cow_file_range_inline(struct btrfs_trans_handle *trans,
 	ret = insert_inline_extent(trans, root, inode, start,
 				   inline_len, compressed_size,
 				   compress_type, compressed_pages);
-	if (ret) {
+	if (ret && ret != -ENOSPC) {
 		btrfs_abort_transaction(trans, root, ret);
 		return ret;
+	} else if (ret == -ENOSPC) {
+		return 1;
 	}
+
 	btrfs_delalloc_release_metadata(inode, end + 1 - start);
 	btrfs_drop_extent_cache(inode, start, aligned_end - 1, 0);
 	return 0;
-- 
1.7.7.6


[-- Attachment #3: Type: text/plain, Size: 258 bytes --]



-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer

             reply	other threads:[~2012-06-13  4:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13  3:46 Alexandre Oliva [this message]
2012-06-13  5:04 ` ceph-on-btrfs inline-cow regression fix for 3.4.3 Chris Samuel
2012-06-13 14:33 ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=orvcivvppp.fsf@livre.localdomain \
    --to=oliva@lsd.ic.unicamp.br \
    --cc=ceph-devel@vger.kernel.org \
    --cc=chris.mason@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox