. With this patch I was able to
successfully mount my file system. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2: replace PTR_ERR() with PTR_RET(), thats what I meant to do
fs/btrfs/root-tree.c | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
diff
On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
From: Jie Liu jeff@oracle.com
Create a small file and fallocate it to a big size with
FALLOC_FL_KEEP_SIZE option, then truncate it back to the
small size again, the disk free space is not changed back
in this case. i.e,
# dd
On Fri, Jun 28, 2013 at 09:07:49PM +0800, Jeff Liu wrote:
On 06/28/2013 08:41 PM, Josef Bacik wrote:
On Fri, Jun 28, 2013 at 01:15:52PM +0800, Jeff Liu wrote:
From: Jie Liu jeff@oracle.com
Create a small file and fallocate it to a big size with
FALLOC_FL_KEEP_SIZE option
On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
On kernel 3.8.13:
Using two equal performance SATAII HDDs, formatted for btrfs raid1 for
both data and metadata and:
The second disk appears to suffer about x8 the read activity of the
first disk. This causes the second disk to
On Fri, Jun 28, 2013 at 09:55:31AM -0700, George Mitchell wrote:
On 06/28/2013 09:25 AM, Martin wrote:
On 28/06/13 16:39, Hugo Mills wrote:
On Fri, Jun 28, 2013 at 11:34:18AM -0400, Josef Bacik wrote:
On Fri, Jun 28, 2013 at 02:59:45PM +0100, Martin wrote:
On kernel 3.8.13:
Using two equal
On Fri, Jun 28, 2013 at 10:25:39AM +0800, Liu Bo wrote:
Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
old data to new
fine, but it won't find
the skinny metadata extent refs. With this patch I'm not seeing warnings
anymore. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/backref.c | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs
On Thu, Jun 27, 2013 at 02:33:20PM -0700, Zach Brown wrote:
Reviewing as requested! It certainly looks reasonable, but I don't have
enough history with the code to really say much more than that.
Some questions:
@@ -8423,6 +8432,10 @@ void btrfs_create_pending_block_groups(struct
btrfs fi defrag {} \;
Thansk,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/ctree.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index c32d03d..7921e1d 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
forward in the tree mod entries, otherwise we'll end up with random entries
and
trip the BUG_ON() at the front
On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote:
Hi Josef,
On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi Josef,
Can you please help me with another question.
I am looking at your patch:
Btrfs: fix chunk allocation error handling
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
forward in the tree mod entries, otherwise we'll end up with random entries
and
trip the BUG_ON() at the front
On Sun, Jun 30, 2013 at 11:02:10PM +0800, Liu Bo wrote:
On Sun, Jun 30, 2013 at 07:22:00AM -0400, Josef Bacik wrote:
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since
On Tue, Jun 04, 2013 at 06:17:54PM -0400, Zach Brown wrote:
Hi gang,
I finally sat down to fix that readdir hang that has been in the back
of my mind for a while. I *hope* that the fix is pretty simple: just
don't manufacture a fake f_pos, I *think* we can abuse f_version as an
indicator
Lets try and be consistent with every other alloc() type function.
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/ctree.c | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 7921e1d..32e30ad
On Mon, Jul 01, 2013 at 09:30:43AM -0400, Josef Bacik wrote:
Lets try and be consistent with every other alloc() type function.
Signed-off-by: Josef Bacik jba...@fusionio.com
Ignore this, I didn't compile it and I should have, and I'm just going to delete
this function anyway. Thanks,
Josef
On Mon, Jul 01, 2013 at 10:13:26PM +0800, Liu Bo wrote:
For partial extents, snapshot-aware defrag does not work as expected,
since
a) we use the wrong logical offset to search for parents, which should be
disk_bytenr + extent_offset, not just disk_bytenr,
b) 'offset' returned by the
don't
need to track modifications, and if those pass then do our allocation, and then
when we go to insert the new modification check if we still care, and if we
don't just free up our mod and return. Otherwise we're good to go and we can
carry on. Thanks,
Signed-off-by: Josef Bacik jba
On Mon, Jul 01, 2013 at 05:19:21PM +0200, Koen De Wit wrote:
This testscript creates reflinks to files on different subvolumes,
overwrites the original files and reflinks, and moves reflinked files
between subvolumes.
Originally submitted as testcase 302, changes are made based on comments
On Mon, Jul 01, 2013 at 05:58:44PM +0200, Koen De Wit wrote:
Thanks Eric for reviewing and improving testcases btrfs/306, 309, 310 and
311 !
I had just one comment: on line 70 the output was redirected to $seqres.fll
instead of $seqres.full. Corrected patch below.
# Check if creating a
130 pass when you mount with -o
compress-force=lzo. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/inode.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index b7fa96f..4384c7c 100644
--- a/fs/btrfs/inode.c
. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/generic/256 |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/generic/256 b/tests/generic/256
index 4a53da8..cfe7237 100755
--- a/tests/generic/256
+++ b/tests/generic/256
@@ -165,7 +165,7
On Thu, Jul 04, 2013 at 10:52:39PM +0300, Alex Lyakas wrote:
Hi David,
On Thu, Jul 4, 2013 at 8:03 PM, David Sterba dste...@suse.cz wrote:
On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote:
@@ -7363,6 +7365,12 @@ int btrfs_drop_snapshot(struct btrfs_root *root,
On Thu, Jul 04, 2013 at 04:14:23PM +0200, Stefan Behrens wrote:
Miao Xie reported the following issue:
The filesystem was corrupted after we did a device replace.
Steps to reproduce:
# mkfs.btrfs -f -m single -d raid10 device0..device3
# mount device0 mnt
# btrfs replace start -rfB 1
that isn't at all within
the area we have allocated on disk. Fix this by returning the start of the
extent if it is compressed no matter what the offset. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent_io.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions
extents because the
offsets are for the uncompressed size, not the compressed size. So instead only
do this check if we are not compressed, that way we can get an actual entry for
the physical offset rather than nothing for compressed. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs
on my vm with compress-force=lzo
set. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/backref.c | 25 ++---
1 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 30dbe1c..8bc5e8c 100644
--- a/fs/btrfs
]--;
btrfs_item_key_to_cpu(path-nodes[0], key,
path-slots[0]);
Reviewed-by: Josef Bacik jba...@fusionio.com
Thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
= bytenr;
key.type = BTRFS_EXTENT_ITEM_KEY;
key.offset = root-leafsize;
metadata = 0;
Reviewed-by: Josef Bacik jba...@fusionio.com
Thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs
class to what it is
supposed to be, which blows lockdeps' mind. This patch should fix the problem,
it appears to be the only place where we do this sort of thing. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c |2 ++
1 files changed, 2 insertions(+), 0
/O errors at some point.
I found a thread about the issue
(http://comments.gmane.org/gmane.comp.file-systems.btrfs/20538) and also a
bug report against Qemu from Josef Bacik describing the exact same problem:
https://bugzilla.redhat.com/show_bug.cgi?id=693530 - Josef states it should
be fixed
On Mon, Jul 08, 2013 at 08:46:17AM +0200, Franziska Näpelt wrote:
Hi everybody,
we are using a btrfs RAID 1 with four 2TB hard drives on a Debian 7.1
(Kernel 3.9.6).
After about one year of working, there was an error in messages log and the
filesystem was mounted read-only.
After that
On Wed, Jul 10, 2013 at 12:54:44PM +1000, Russell Coker wrote:
There are two uses of backups, recovering from user errors (IE deleting the
wrong file) and recovering from sysadmin errors or hardware failures (IE
disks
are dead or wiped). For the former use I'm mainly using BTRFS snapshots
fsck complaining. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/file.c | 62 +++---
1 files changed, 40 insertions(+), 22 deletions(-)
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 2d70849..dda2efb 100644
--- a/fs/btrfs
On Thu, Jul 11, 2013 at 01:25:39PM +0800, Miao Xie wrote:
It is unnecessary to unlock the extent by the page size, we can do it
in batches, it makes the random read be faster by ~6%.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/extent_io.c | 70
can't
find the extent we left off at because we never updated it. This patch fixes
the problem.
Cc: sta...@vger.kernel.org
Reported-by: Alex Lyakas alex.bt...@zadarastorage.com
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c | 14 --
1 files changed, 8
On Sun, Jul 14, 2013 at 07:20:04PM +0300, Alex Lyakas wrote:
Hi,
On Thu, Jul 4, 2013 at 10:52 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi David,
On Thu, Jul 4, 2013 at 8:03 PM, David Sterba dste...@suse.cz wrote:
On Thu, Jul 04, 2013 at 06:29:23PM +0300, Alex Lyakas wrote:
...@zadarastorage.com
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 8c204e1..997a5dd 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
On Wed, Jul 17, 2013 at 05:44:23PM -0500, Jon Nelson wrote:
I had a btrfs filesystem under 3.9.8 that failed /hard/ today. So hard
that the filesystem could not be mounted because there wasn't enough
free space, unless it was mounted read only.
This happened after I ran out of metadata space
On Thu, Jul 18, 2013 at 04:21:28PM +0100, Hugo Mills wrote:
On Thu, Jul 18, 2013 at 11:11:03AM -0400, Sandy McArthur wrote:
Should I interpret the different used amounts (902.01GB vs 902.03GB)
on my recovered RAID1 filesystem as that not all data is actually
mirrored and so I should run a
of your tree, hopefully that's the right thing.
Thanks,
Josef Bacik (3):
Btrfs: update drop progress before stopping snapshot dropping
Btrfs: fix lock leak when resuming snapshot deletion
Btrfs: re-add root to dead root list if we stop dropping it
Stefan Behrens (1):
Btrfs
have duplicate
code. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/tree-log.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index 2c67914..ff60d89 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
this and get
uneccessary warnings. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/inode.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index dd05238..a3a6155 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
it won't be on the list of roots to
cleanup. With this patch my reproducer no longer panics. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent-tree.c |2 +-
fs/btrfs/relocation.c |7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs
On Tue, Jul 23, 2013 at 06:39:57PM -0500, Jerome Haltom wrote:
Yeah. I was merely curious about the architecture limits that drove
the design this way, to begin with. Mostly because it seems odd. It
seems like the most obvious and most natural thing from the user's
perspective to do would just
A user reported a panic when running with autodefrag and deleting snapshots.
This is because we could end up trying to add the root to the dead roots list
twice. To fix this check to see if we are empty before adding ourselves to the
dead roots list. Thanks,
Signed-off-by: Josef Bacik jba
On Fri, Jul 26, 2013 at 11:38:47AM +0200, Stefan Behrens wrote:
On Thu, 25 Jul 2013 15:13:40 -0400, Josef Bacik wrote:
A user reported a panic when running with autodefrag and deleting snapshots.
This is because we could end up trying to add the root to the dead roots
list
twice. To fix
We can end up with inodes on the auto defrag list that exist on roots that are
going to be deleted. This is extra work we don't need to do, so just bail if
our root has 0 root refs. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/file.c |5 +
1 files changed, 5
-by: Josef Bacik jba...@fusionio.com
---
tests/generic/314 |2 +-
tests/generic/314.out |1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/tests/generic/314 b/tests/generic/314
index 2d34ea8..0dd98a3 100644
--- a/tests/generic/314
+++ b/tests/generic/314
@@ -62,7 +62,7
to the pages.
This is because I'm going to fix what extent bits we clear in some cases and
rather than add a bunch of new flags we'll just use the actual extent bits we
want to clear. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/extent_io.c | 32 ---
fs/btrfs
failling because the df
after the test is slightly off (in my case it was like 36kb off). With this
patch I'm not seeing random failures of this test. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/generic/315 |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
adding an ordered extent
then we need to make sure the enospc handling stuff is accounted for. Also if
this range was DEFRAG we need to make sure that bit is cleared so we dont leak
it. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/inode.c | 46
On Mon, Jul 29, 2013 at 12:38:25PM -0500, Eric Sandeen wrote:
On 7/29/13 12:31 PM, Eric Sandeen wrote:
Honest question: does one more sync make this deterministic, or is it a
best-effort, um, hack?
I'm not quite sure why even 1 sync is needed. :(
Because of COW, we won't free up the
. With this patch I no longer see
transient failures of this test. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/generic/315 |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/tests/generic/315 b/tests/generic/315
index 7cfc40d..9c01b5e 100644
--- a/tests/generic/315
adding an ordered extent
then we need to make sure the enospc handling stuff is accounted for. Also if
this range was DEFRAG we need to make sure that bit is cleared so we dont leak
it. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2:
- only do EXTENT_DO_ACCOUNTING
On Tue, Jul 30, 2013 at 06:11:39PM +0300, Alex Lyakas wrote:
Hi Josef,
On Tue, Apr 23, 2013 at 9:20 PM, Josef Bacik jba...@fusionio.com wrote:
We kept leaking extent buffers when mounting a broken file system and it
turns
out it's because not everybody uses read_tree_block properly
On Tue, Jul 30, 2013 at 11:07:30AM +0200, Geert Uytterhoeven wrote:
On Tue, 30 Jul 2013, Thorsten Glaser wrote:
NEW problem: btrfs doesn’t work at all. I had to reboot my
buildd into 3.2 using echo s/u/s/o /proc/sysrq-trigger as
the attempt to mount it left the system hanging there.
[
from doing extra work.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/relocation.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 5a23d87..8168fb3 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs
BUG_ON(!upper-checked). Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/relocation.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 8168fb3..2ec59c4 100644
--- a/fs/btrfs/relocation.c
+++ b
On Tue, Jul 30, 2013 at 07:02:29PM +, Thorsten Glaser wrote:
Josef Bacik dixit:
Can you gdb btrfs.ko and do
list *(__btrfs_map_block+0x11c)
Not easily (the kernel image is from a .deb package),
and even in a compile tree gdb just says:
No symbol table is loaded. Use the file
On Wed, Jul 31, 2013 at 02:19:25PM +0200, tim wrote:
running btrfs on kernel 3.10.3, i got the following two backtraces,
first an info about a hung task and a kernel bug.
are these known issues?
Well that's not good, can you file a bugzilla with this at bugzilla.kernel.org?
Make sure the
Alexandre pointed out that his xattrs have sensitive information in them as
well, so fix btrfs-image to zero out the data part of xattrs that we find.
Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
btrfs-image.c | 19 +++
1 files changed, 19 insertions(+), 0
There is no reason for this sort of jackassery. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/transaction.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 18f7e71..ea8d522 100644
--- a/fs
On Wed, Jul 31, 2013 at 11:37:40PM +0800, Liu Bo wrote:
Data deduplication is a specialized data compression technique for eliminating
duplicate copies of repeating data.[1]
This patch set is also related to Content based storage in project ideas[2].
PATCH 1 is a hang fix with
On Fri, Aug 02, 2013 at 06:08:01PM +0800, Miao Xie wrote:
Hi, Josef
On Tue, 30 Jul 2013 14:27:40 +0800, Miao Xie wrote:
extent_clear_unlock_delalloc(inode, start, end, NULL,
- EXTENT_DIRTY |
-
On Thu, Aug 01, 2013 at 05:05:35PM +0300, Alex Lyakas wrote:
Hi Josef,
On Thu, May 30, 2013 at 11:58 PM, Josef Bacik jba...@fusionio.com wrote:
Dave reported a panic because the extent_root-commit_root was NULL in the
caching kthread. That is because we just unset it in free_root_pointers
in case of error and
makes everybody bail out if we have an error. Alex tested and verified this
patch fixed his problem. This fixes bz 59431. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/ctree.h |1 +
fs/btrfs/extent-tree.c | 27 ---
2 files
On Wed, Jul 24, 2013 at 05:07:28PM +0200, Jan Schmidt wrote:
fssum is a tool to build a recursive checksum for a file system. The home
repository of fssum is
git://git.kernel.org/pub/scm/linux/kernel/git/arne/far-progs.git
It is added as an optional target, because it depends on glibc
/btrfs/group b/tests/btrfs/group
index bc6c256..11d708a 100644
--- a/tests/btrfs/group
+++ b/tests/btrfs/group
@@ -9,3 +9,4 @@
276 auto rw metadata
284 auto
307 auto quick
+316 auto rw metadata
I applied and ran this locally and gave everything a look over, you can add
Reviewed-by: Josef
it would have been completely destroyed. This fixes bz
60673. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/send.c | 28 ++--
1 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index d3f3b43..ab82473
it would have been completely destroyed. This fixes bz
60673. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2: remove the debugging stuff
fs/btrfs/send.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs
There was a problem with send trying to overwrite a file that wasn't actually
the same. This is a test to check this particular case where receive fails when
it should succeed properly. I tested this to verify it fails without my fix and
passes with my fix. Thanks,
Signed-off-by: Josef Bacik
We can get ENOMEM trying to allocate dummy bufs for the rewind operation of the
tree mod log. Instead of BUG_ON()'ing in this case pass up ENOMEM. I looked
back through the callers and I'm pretty sure I got everybody who did BUG_ON(ret)
in this path. Thanks,
Signed-off-by: Josef Bacik jba
On Thu, Aug 08, 2013 at 02:17:05AM +0800, Tomasz Chmielewski wrote:
One of btrfs filesystems hanged on my server.
By hang, I mean it's not possible to finish any write operation, i.e.:
# cd /mnt/btrfs
# ls
some-file
# touch 1
[it never returns to shell here]
I've just posted a
We can get ENOMEM trying to allocate dummy bufs for the rewind operation of the
tree mod log. Instead of BUG_ON()'ing in this case pass up ENOMEM. I looked
back through the callers and I'm pretty sure I got everybody who did BUG_ON(ret)
in this path. Thanks,
Signed-off-by: Josef Bacik jba
On Wed, Aug 07, 2013 at 01:02:30PM -0700, Zach Brown wrote:
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -1211,7 +1211,8 @@ tree_mod_log_rewind(struct btrfs_fs_info *fs_info,
struct extent_buffer *eb,
BUG_ON(tm-slot != 0);
eb_rewin =
On Wed, Aug 07, 2013 at 01:18:26PM -0700, Christoph Hellwig wrote:
On Wed, Aug 07, 2013 at 12:57:18PM -0700, Mark Fasheh wrote:
stat(2) on btrfs returns a custom device, but proc uses s_dev from the super
block. This causes problems (abi breakage) because software (and users) are
not
We can get ENOMEM trying to allocate dummy bufs for the rewind operation of the
tree mod log. Instead of BUG_ON()'ing in this case pass up ENOMEM. I looked
back through the callers and I'm pretty sure I got everybody who did BUG_ON(ret)
in this path. Thanks,
Signed-off-by: Josef Bacik jba
There is no reason we can't just set the path to blocking and then do normal
GFP_NOFS allocations for these extent buffers. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/ctree.c | 16 ++--
fs/btrfs/extent_io.c |8
2 files changed, 14
On Thu, Aug 08, 2013 at 05:13:49AM -0700, Christoph Hellwig wrote:
On Wed, Aug 07, 2013 at 04:51:46PM -0400, Josef Bacik wrote:
Not possible, this will break other things as subvolumes have their own
inode
space, it will confuse applications that get multiples of an inode number
On Thu, Aug 08, 2013 at 09:36:52AM +0200, Jan Schmidt wrote:
On Wed, August 07, 2013 at 23:03 (+0200), Josef Bacik wrote:
We can get ENOMEM trying to allocate dummy bufs for the rewind operation of
the
tree mod log. Instead of BUG_ON()'ing in this case pass up ENOMEM. I
looked
back
On Thu, Aug 08, 2013 at 09:23:06AM +0200, Jan Schmidt wrote:
On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
There is no reason we can't just set the path to blocking and then do normal
GFP_NOFS allocations for these extent buffers. Thanks,
Signed-off-by: Josef Bacik jba
On Wed, Aug 07, 2013 at 01:12:29PM +0800, Wang Shilong wrote:
When disabling quota, we should clear out list 'dirty_qgroups',otherwise,
we will get oops if enabling quota again. Fix this by abstracting similar
code from del_qgroup_rb().
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
On Thu, Aug 08, 2013 at 06:48:05AM -0700, Christoph Hellwig wrote:
On Thu, Aug 08, 2013 at 09:02:07AM -0400, Josef Bacik wrote:
This won't work, try having 1 subvolumes with dirty inodes and do sync
then
go skiing, you'll have time :). Thanks,
Why would the dirty inodes make any
On Thu, Aug 08, 2013 at 06:48:05AM -0700, Christoph Hellwig wrote:
On Thu, Aug 08, 2013 at 09:02:07AM -0400, Josef Bacik wrote:
This won't work, try having 1 subvolumes with dirty inodes and do sync
then
go skiing, you'll have time :). Thanks,
Why would the dirty inodes make any
On Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
Phoronix periodically runs benchmarks on filesystems, and one thing I
have noticed is that btrfs always does terribly on their fio Intel
IOMeter fileserver access pattern benchmark:
On Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
Phoronix periodically runs benchmarks on filesystems, and one thing I
have noticed is that btrfs always does terribly on their fio Intel
IOMeter fileserver access pattern benchmark:
On Thu, Aug 08, 2013 at 01:23:22PM -0700, John Williams wrote:
On Thu, Aug 8, 2013 at 12:40 PM, Josef Bacik jba...@fusionio.com wrote:
On Thu, Aug 08, 2013 at 09:13:04AM -0700, John Williams wrote:
Phoronix periodically runs benchmarks on filesystems, and one thing I
have noticed
On Thu, Jun 27, 2013 at 12:40:30AM +0200, Gabriel de Perthuis wrote:
---
The matching kernel patch is here:
https://github.com/g2p/linux/tree/v3.10%2Bextent-same (rebased on 3.10,
fixing a small conflict)
Requires the btrfs-extent-same command:
-
On Fri, Aug 09, 2013 at 02:30:38PM +0200, Andreas Schwab wrote:
Andreas Schwab sch...@linux-m68k.org writes:
Josef Bacik jba...@fusionio.com writes:
So stripe_len shouldn't be 0, if it is you have bigger problems :).
The bigger problem is that stripe_nr is u64, this is completely
On Fri, Aug 09, 2013 at 11:35:33PM +0200, Kai Krakow wrote:
Josef Bacik jba...@fusionio.com schrieb:
So I guess the reason that ZFS does well with that workload is that
ZFS is using smaller blocks, maybe just 512B ?
Yeah I'm not sure what ZFS does, but if you are writing over a block
at that previous
point. The problem is if we have subvols in that directory these will always be
lower since they are set to the first free objectid. To fix this we just skip
entries with that inode number. Thanks,
Reported-by: Emil Karlson jekarl...@gmail.com
Signed-off-by: Josef Bacik jba
On Sun, Aug 11, 2013 at 09:53:01PM +0300, Emil Karlson wrote:
Greetings
Send fails for me unexpectedly:
I get:
ERROR: rename o262-5-0 - snapshots failed. No such file or directory
reproducer ( http://users.tkk.fi/~jkarlson/files/test4.txt ):
for i in 1 2; do
mkdir /mnt/$i
On Mon, Aug 12, 2013 at 05:16:04PM +0200, Stefan Behrens wrote:
On Mon, 12 Aug 2013 10:59:52 -0400, Josef Bacik wrote:
On Sun, Aug 11, 2013 at 09:53:01PM +0300, Emil Karlson wrote:
Greetings
Send fails for me unexpectedly:
I get:
ERROR: rename o262-5-0 - snapshots failed
create. Thanks,
Reported-by: Emil Karlson jekarl...@gmail.com
Signed-off-by: Josef Bacik jba...@fusionio.com
---
V1-V2: fix it properly
fs/btrfs/send.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index 0efc2e2..f8f8b1f 100644
. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/btrfs/002 | 85 +++
tests/btrfs/002.out |2 +
tests/btrfs/group |1 +
3 files changed, 88 insertions(+), 0 deletions(-)
create mode 100755 tests/btrfs/002
create mode
are trying to delete, and if
it does not allowing it to happen. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/ioctl.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 2312c0f..107c5f4 100644
--- a/fs
We were allowing users to delete their default subvolume, which is problematic.
This test is a regression test to make sure we don't let that happen in the
future. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/btrfs/003 | 64
On Mon, Aug 12, 2013 at 11:06:27PM -0500, Mitch Harder wrote:
I'm hitting a btrfs Kernel BUG running a snapshot stress script with
linux-3.11.0-rc5.
I can haz script? Thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to
On Tue, Aug 13, 2013 at 10:28:59AM +0900, dima wrote:
Hello all,
About a week or so ago I noticed that [btrfs-ino-cache] process was
appearing in the 'top' on each reboot and disk is spinning like crazy for
about five minutes or so. Quite so often this caused X failing to start
because all
101 - 200 of 3265 matches
Mail list logo
