On 2014/10/02 01:31, Duncan wrote:
Niklas Fischer posted on Wed, 01 Oct 2014 22:29:55 +0200 as excerpted:
I was trying to determine how btrfs reacts to disk errors, when I
discovered, that flipping two Bytes, supposedly inside of a file can
render the filesystem unusable. Here is what I did:
On Thu, Oct 02, 2014 at 12:05:39AM -0500, Justin Brown wrote:
I'm experimenting with btrfs-send. Previously (2014-09-26), I did my
first btrfs-send on a subvol, and that worked fine. Today, I tried to
send a new snapshot. Unfortunately, I realized part way through that I
forgot to specify the
(I am unable to reproduce the issue, tried to go back with progs versions
but still the same. So as of now this code remains untested, suggest to
wait till we have a reproducible test case).
Here is a test case which says it all..
mkfs.xfs -f $DEV
mkfs.btrfs -f $DEV
mount $DEV $MNT
mount:
Got this when running balance with 3.17.0-rc7:
(...)
[173394.571080] BTRFS info (device sdd1): relocating block group
4391666974720 flags 17
[173405.407779] BTRFS info (device sdd1): found 52296 extents
[173441.235837] BTRFS info (device sdd1): found 52296 extents
[173442.266918] BTRFS info
Hugo,
Many thanks for the help. That was far easier than I was anticipating. :)
Now that I have that cleaned up, I'm having trouble with sending the
delta. Perhaps this is a limitation of send/receive because it seems
odd that btrfs-receive doesn't have a parent option.
I'm sending a snapshot
chunk-recover.c: In function ‘btrfs_calc_stripe_index’:
chunk-recover.c:1481: warning: ‘index’ may be used uninitialized in this
function
Signed-off-by: Anand Jain anand.j...@oracle.com
---
chunk-recover.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/chunk-recover.c
Hi all,
I just noticed that when doing a 'btrfs subvolume show /' I get the
error 'ERROR: / doesn't belong to btrfs mount point', which is not quite
true. I get the same error for all the other subvolumes as well. It
worked fine until 3.14.1.
Regards,
--
J.Hofmüller
ich zitiere wie
Brendan Hide posted on Thu, 02 Oct 2014 07:51:08 +0200 as excerpted:
A reasonable workaround to get the filesystem back into a usable or
recoverable state might be to mount read-only and ignore checksums. That
would keep the filesystem intact, though the system has no way to know
whether or
Hi,
I have a large (25G) virtual disk on a btrfs fs. Yes, I know this is not
optimial. So I try to defrag it from time to time. However, using btrfs fi
defrag -c vm.vdi results in even more fragments than before (reported by
filefrag). So I wrote my own pseudo defragger,
-
#!/bin/sh
test
Assorted cleanups. There's fix from Filipe mixed among my patches because I
found it in the mailinglist but only after I had written my own patch of
course.
You can pull from
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
cleanup/misc-for-3.18
David Sterba (13):
btrfs:
From: Filipe David Borba Manana fdman...@gmail.com
8MiB is way too large and likely set by mistake. This is not
a significant issue as in practice the max amount of data
added to an inline extent is also limited by the page cache
and btree leaf sizes.
Signed-off-by: Filipe David Borba Manana
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/super.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 2375f94fb780..1c6da8e00c1b 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -395,7 +395,6 @@ int
The enum exists but is not consistently used.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/compression.c | 11 +++
fs/btrfs/disk-io.c | 14 +++---
fs/btrfs/disk-io.h | 4 ++--
fs/btrfs/inode.c | 3 ++-
4 files changed, 14 insertions(+), 18 deletions(-)
The last users are long gone.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent_io.h | 4
1 file changed, 4 deletions(-)
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index 5e91fb9d1764..1e06f0e4a185 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c | 3 +--
fs/btrfs/send.c| 2 +-
fs/btrfs/transaction.c | 2 +-
fs/btrfs/transaction.h | 2 +-
4 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index
The structure is frequently reused. Rename it according to the slab
name.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/disk-io.c | 38 +-
fs/btrfs/disk-io.h | 2 ++
fs/btrfs/super.c | 8 +++-
3 files changed, 38 insertions(+), 10
btrfs_interface_init rarely fails but we could leak the prelim_ref slab.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/super.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index b1d2a42f379d..b915d7704f19 100644
---
Signed type mismatches the ioctl structure, all extent calculations are
done on unsigned types.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ioctl.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/scrub.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
index b9c37ac9ed1b..efa083113827 100644
--- a/fs/btrfs/scrub.c
+++ b/fs/btrfs/scrub.c
@@ -177,17 +177,12 @@
Use a common definition for the inline data start so we don't have to
open-code it and introduce bugs like Btrfs: fix wrong max inline data
size limit fixed.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c | 3 +--
fs/btrfs/ctree.h | 16
2 files changed, 9
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/relocation.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 2d221c46180c..f39abe690bb2 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2316,7
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c | 5 ++---
fs/btrfs/ctree.h | 9 +
fs/btrfs/disk-io.c | 4 +---
fs/btrfs/extent-tree.c | 16 +++-
fs/btrfs/qgroup.c | 10 --
5 files changed, 23 insertions(+), 21 deletions(-)
All callers use the same value, simplify the function.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent_io.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 78229007f99e..638e1a5b00e2 100644
---
It used to be more complex but now it's just a simple array access.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/extent_io.c | 55 +---
fs/btrfs/extent_io.h | 6 --
2 files changed, 26 insertions(+), 35 deletions(-)
diff --git
First portion of cleanups that remove a parameter that's being passed to a lot
of functions, although the value does not change during the filesystem
lifetime. This part contains the obvious and safe changes, but there are more
pending that start to touch functionality and haven't not passed
Rename to btrfs_alloc_tree_block as it fits to the alloc/find/free +
_tree_block family. The parameter blocksize was set to the metadata
block size, directly or indirectly.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c | 26 +++---
fs/btrfs/ctree.h
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/ctree.c | 12 +---
fs/btrfs/disk-io.c | 5 ++---
fs/btrfs/disk-io.h | 2 +-
fs/btrfs/extent-tree.c | 2 +-
4 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index
The parent_transid parameter has been unused since its introduction in
ca7a79ad8dbe2466 (Pass down the expected generation number when reading
tree blocks). In reada_tree_block, it was even wrongly set to leafsize.
Transid check is done in the proper read and readahead ignores errors.
We know the tree block size, no need to pass it around.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/backref.c | 6 ++
fs/btrfs/ctree.c | 10 +++---
fs/btrfs/disk-io.c | 17 +
fs/btrfs/disk-io.h | 2 +-
fs/btrfs/extent-tree.c | 8 +++-
It's trivial with a single user. And remove one pointless BUG_ON.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/relocation.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 16cb2b4a9620..d7506325b024
Two patches removing some 'unlikely' branch hints where it does not make much
sense. Sent separately from the other cleanups in case they do not seem to fit.
You can pull from
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git remove-unlikely
David Sterba (2):
btrfs: remove
Unlikely is implicit for NULL checks of pointers.
Signed-off-by: David Sterba dste...@suse.cz
---
fs/btrfs/async-thread.c | 10 +-
fs/btrfs/inode.c| 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c
index
There are the branch hints that obviously depend on the data being
processed, the CPU predictor will do better job according to the actual
load. It also does not make sense to use the hints in slow paths that do
a lot of other operations like locking, waiting or IO.
Signed-off-by: David Sterba
If scrub is not cancelled nor finished, the recorded status will prevent
scrub to start again though it's not running. There's a force option to
run it anyway, but this is just a bandaid and the true status of scrub
should be detected automatically. The force option should not be
necessary
If between two snapshots we rename an existing directory named X to Y and
make it a child (direct or not) of a new inode named X, we were delaying
the move/rename of the former directory unnecessarily, which would result
in attempting to rename the new directory from its orphan name to name X
This is a regression test for a btrfs incremental send issue.
If between two snapshots we rename an existing directory named X to Y and
make it a child (direct or not) of a new inode named X, we were delaying
the move/rename of the former directory unnecessarily, which would result
in attempting
On Thu, Oct 02, 2014 at 05:13:22PM +0200, Marc Dietrich wrote:
I have a large (25G) virtual disk on a btrfs fs. Yes, I know this is not
optimial. So I try to defrag it from time to time. However, using btrfs fi
defrag -c vm.vdi results in even more fragments than before (reported by
On Thu, Oct 02, 2014 at 07:25:49PM +0200, David Sterba wrote:
On Thu, Oct 02, 2014 at 05:13:22PM +0200, Marc Dietrich wrote:
I have a large (25G) virtual disk on a btrfs fs. Yes, I know this is not
optimial. So I try to defrag it from time to time. However, using btrfs fi
defrag -c vm.vdi
On 2014/10/02 07:51, Brendan Hide wrote:
On 2014/10/02 01:31, Duncan wrote:
[snip]
I'm not sure if there is a mount option for this use case however. The
option descriptions for nodatasum and nodatacow imply that *new*
checksums are not generated. In this case the checksums already exist.
Somtetimes you just need to delete an item, add that functionality to
btrfs-corrupt-block. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
btrfs-corrupt-block.c | 47 ++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git
If we have an inode backref entry then we know enough to add back a missing dir
index. When messing with the inode backrefs we need to do all of that first
before we process the inode recs themselves as we may clear errors on the inode
recs as we fix the directory indexes. This adds the
For testing fsck against completely broken btrfs_items.
Signed-off-by: Josef Bacik jba...@fb.com
---
btrfs-corrupt-block.c | 90 +--
1 file changed, 88 insertions(+), 2 deletions(-)
diff --git a/btrfs-corrupt-block.c b/btrfs-corrupt-block.c
index
Am Donnerstag 02 Oktober 2014, 19:25:49 schrieb David Sterba:
On Thu, Oct 02, 2014 at 05:13:22PM +0200, Marc Dietrich wrote:
I have a large (25G) virtual disk on a btrfs fs. Yes, I know this is not
optimial. So I try to defrag it from time to time. However, using btrfs
fi
defrag -c vm.vdi
Am Donnerstag 02 Oktober 2014, 21:55:55 schrieb Marc Dietrich:
Will try to restore the file using btrfs restore
ok, restore worked. I did some more tests. This is unrelated to CoW. It seems
that the fallocate -n in combination with dd conv=notrunc using large
files (10G) triggers it. Maybe
44 matches
Mail list logo
