Hi!
I have two Hardware-Raid Arrays. Each encrypted with dmcrypt and on each
one btrfs on it (without snapshots). They are half-filled
I do rsyncs on these fs over night and i get these errors:
INFO: task flush-btrfs-2:1472 blocked for more than 120 seconds.
echo 0
To reproduce this bug:
# dd if=/dev/zero of=img bs=1M count=256
# mkfs.btrfs img
# losetup -r /dev/loop1 img
# mount /dev/loop1 /mnt
OOPS!!
It triggered BUG_ON(!nr_devices) in btrfs_calc_avail_data_space().
To fix this, instead of checking write-only devices, we check all open
If we call ioctl(BTRFS_IOC_ADD_DEV) directly, we'll succeed in adding
a readonly device to a btrfs filesystem, and btrfs will write to
that device, emitting kernel errors:
[ 3109.833692] lost page write due to I/O error on loop2
[ 3109.833720] lost page write due to I/O error on loop2
...
Hi Tobias,
On Mon, 28 Nov 2011, 19:16:25 EST, Tobias tra...@robotech.de wrote:
The problem occurs on the stock ubuntu kernel 2.6.38-8, 3.0.0-12,
3.0.0-13 and on my self-compiled 3.1.2.
There's a lot of work gone into btrfs in 3.2,
it would be interesting to know (speaking as
just another
Hi,
Andy Whitcroft wrote:
When we mount a btrfs filesystem from read-only media there will be no
read/write devices; for example mounting an SD card with its lock enabled.
This triggers an immediate BUG during mount:
kernel BUG at .../fs/btrfs/super.c:984!
[...]
BugLink:
On Mon, Nov 28, 2011 at 06:11:06AM -0600, Jonathan Nieder wrote:
Hi,
Andy Whitcroft wrote:
When we mount a btrfs filesystem from read-only media there will be no
read/write devices; for example mounting an SD card with its lock enabled.
This triggers an immediate BUG during mount:
We're failing to create clusters with bitmaps because
setup_cluster_no_bitmap checks that the list is empty before inserting
the bitmap entry in the list for setup_cluster_bitmap, but the list
field is only initialized when it is restored from the on-disk free
space cache, or when it is written
On Mon, Nov 21, 2011 at 06:10:19PM +0800, Liu Bo wrote:
We've been sufferring two big bugs with sub transid:
one is a bug related to root's last_snapshot, the other is a bug related to
disk extent refs' generation.
Do you have a testcase to trigger and check these bugs?
1) The first patch
This tool draws per-chunk pngs representing the allocation map. A black
or colored dot means the block is allocated.
The output is written to a subdirectory, together with an index.html to be
viewed in a browser.
There are options to control whether color should be used and which block
group types
Seems I've picked up a wireless regression, and randomly drop my WiFi
connection with more recent kernels. While I'd love to try to track down the
issue, the sporadic nature makes it difficult. But I don't want to revert to a
flat-out old kernel because of all the btrfs modifications. Is it
---
fs/btrfs/extent-tree.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 5d86877..bc0f13d 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -5304,7 +5304,7 @@ alloc:
/*
The first 11 patches are relatively simple fixes or improvements that
I suppose go could make it even in 3.2 (02 is particularly essential
to avoid progressive performance degradation and metadata space waste
in the default clustered allocation strategy).
Patch 12 and its complement 15, and also
When we find an existing cluster, we switch to its block group as the
current block group, possibly skipping multiple blocks in the process.
Furthermore, under heavy contention, multiple threads may fail to
allocate from a cluster and then release just-created clusters just to
proceed to create
We store the allocation start and length twice in ins, once right
after the other, but with intervening calls that may prevent the
duplicate from being optimized out by the compiler. Remove one of the
assignments.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/extent-tree.c
The field that indicates the size of the largest contiguous chunk of
free space in the cluster is not initialized when setting up bitmaps,
it's only increased when we find a larger contiguous chunk. We end up
retaining a larger value than appropriate for highly-fragmented
clusters, which may
---
fs/btrfs/free-space-cache.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 953f7dd..0151274 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -2316,6 +2316,16 @@
With -o mincluster, we save the location of the last successful
allocation, so as to emulate some of the cluster allocation logic
(though not non-bitmap preference) without actually going through the
exercise of allocating clusters.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
Experimental patch to be able to compact only the metadata after
excessive block groups are created. I guess it should be implemented
as a balance option rather than a separate ioctl, but this was good
enough for me to try it.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
Instead of starting at zero (offset is always zero), request a cluster
starting at search_start, that denotes the beginning of the current
block group.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/extent-tree.c |6 ++
1 files changed, 2 insertions(+), 4
We try to maintain about 1% of the filesystem space in free space in
data block groups, but we need not do that for metadata, since we only
allocate one block at a time.
This patch also moves the adjustment of flags to account for mixed
data/metadata block groups into the block protected by spin
If we don't have a cluster, don't bother trying to allocate from it,
jumping right away to the attempt to allocate a new cluster.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/extent-tree.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
This patch adds several debug messages that helped me track down
problems in the cluster allocation logic. All the messages are
disabled by default, so that they're optimized away, but enabling the
commented-out settings of debug brings some helpful messages.
Signed-off-by: Alexandre Oliva
We're failing to create clusters with bitmaps because
setup_cluster_no_bitmap checks that the list is empty before inserting
the bitmap entry in the list for setup_cluster_bitmap, but the list
field is only initialized when it is restored from the on-disk free
space cache, or when it is written
Activate various messages that help track down clustered allocation
problems, that are disabled and optimized out by default.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/extent-tree.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git
If we reach LOOP_NO_EMPTY_SIZE, we won't even try to use a cluster that
others might have set up. Odds are that there won't be one, but if
someone else succeeded in setting it up, we might as well use it, even
if we don't try to set up a cluster again.
Signed-off-by: Alexandre Oliva
Enable removal of a second disk even if that requires conversion of
metadata from raid1 to dup, but not when data would lose replication.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/volumes.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
btrfs filesystem balance sometimes fails on corrupted filesystems, but
without any information that explains what the failure was to help
track down the problem. This patch adds logging for nearly all error
conditions that may cause relocation to fail.
Signed-off-by: Alexandre Oliva
Dear David and Liu,
I need to reclaim the drive space being taken up by this perhaps
corrupt btrfs file system. Is there any additional information you
would like before this problem will no longer be reproducible?
Thanks,
Tim
On Fri, Nov 25, 2011 at 11:25 AM, Timothy Crone tjcr...@gmail.com
We test whether a block group has enough free space to hold the
requested block, but when we're doing clustered allocation, we can
save some cycles by testing whether it has enough room for the cluster
upfront, otherwise we end up attempting to set up a cluster and
failing. Only in the
Bitmap lists serve two purposes: recording the order of loading/saving
on-disk free space caches, and setting up a list of bitmaps to try to
set up a cluster. Complain if a list is unexpectedly busy.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/free-space-cache.c |7
Introduce -o nocluster to disable the use of clusters for extent
allocation, and -o cluster to reverse it.
Signed-off-by: Alexandre Oliva ol...@lsd.ic.unicamp.br
---
fs/btrfs/ctree.h |3 ++-
fs/btrfs/extent-tree.c |2 +-
fs/btrfs/super.c | 16 ++--
3 files
Parameterize clusters on minimum total size, minimum chunk size and
minimum contiguous size for at least one chunk, without limits on
cluster, window or gap sizes. Don't tolerate any fragmentation for
SSD_SPREAD; accept it for metadata, but try to keep data dense.
Signed-off-by: Alexandre Oliva
Jeff Mahoney je...@suse.com writes:
The extent_state structure is used at the core of the extent i/o code
for managing flags, locking, etc. It requires allocations deep in the
write code and if failures occur they are difficult to recover from.
We avoid most of the failures by using a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 06:53 PM, Andi Kleen wrote:
Jeff Mahoney je...@suse.com writes:
The extent_state structure is used at the core of the extent i/o
code for managing flags, locking, etc. It requires allocations
deep in the write code and if failures
On Mon, Nov 28, 2011 at 03:47:20PM +0800, Jeff Liu wrote:
For an initial dir inode, stat(1) show it links as 1, IMHO it should be
2 by default.
Yes, this is correct for directories. And newly created subvolumes
should have nlink == 2 as well, can you please add it to your patch?
(I have tested
On 11/28/2011 11:10 PM, David Sterba wrote:
On Mon, Nov 21, 2011 at 06:10:19PM +0800, Liu Bo wrote:
We've been sufferring two big bugs with sub transid:
one is a bug related to root's last_snapshot, the other is a bug related to
disk extent refs' generation.
Do you have a testcase to
Andy Whitcroft wrote:
On Mon, Nov 28, 2011 at 06:11:06AM -0600, Jonathan Nieder wrote:
Hi,
Andy Whitcroft wrote:
When we mount a btrfs filesystem from read-only media there will be no
read/write devices; for example mounting an SD card with its lock enabled.
This triggers an immediate BUG
Hi!
Sending a mail on this issue, as advised on IRC.
My /home file system fails to mount and the kernel seem to freeze and I
need to do the Alt+SysRq RSNEIUB routine to boot it safely.
The corruption happened on a 3.2-rcsomething kernel and Ubuntu 11.10,
but I am now running on Ubuntu 12.04
On mon, 28 Nov 2011 06:11:06 -0600, Jonathan Nieder wrote:
Hi,
Andy Whitcroft wrote:
When we mount a btrfs filesystem from read-only media there will be no
read/write devices; for example mounting an SD card with its lock enabled.
This triggers an immediate BUG during mount:
kernel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/28/2011 12:53 PM, Ken D'Ambrosio wrote:
Seems I've picked up a wireless regression, and randomly drop my WiFi
connection with more recent kernels. While I'd love to try to track down the
issue, the sporadic nature makes it difficult. But I
Alexandre Oliva wrote:
The first 11 patches are relatively simple fixes or improvements that
I suppose go could make it even in 3.2 (02 is particularly essential
to avoid progressive performance degradation and metadata space waste
in the default clustered allocation strategy).
I think 02
On Tue, Nov 29, 2011 at 8:58 AM, Phillip Susi ps...@cfl.rr.com wrote:
On 11/28/2011 12:53 PM, Ken D'Ambrosio wrote:
Seems I've picked up a wireless regression, and randomly drop my WiFi
connection with more recent kernels. While I'd love to try to track down the
issue, the sporadic nature
Li Zefan wrote:
This patch has the same problem with your previous one, that it will set
f_bavail to 0. I've sent out a new patch yesterday.
Thanks for the quick feedback. That makes sense. (The new patch
is at [1], for reference.)
[1]
Please ignore this patch for now, it can cause the file system corrupted
and failed to mount again, sorry for the noise!
-Jeff
On 11/28/2011 03:47 PM, Jeff Liu wrote:
For an initial dir inode, stat(1) show it links as 1, IMHO it should be
2 by default.
Signed-off-by: Jie Liu
Scrub can be invoked to scrub only a single device of a (mounted) filesystem.
The code determines whether the given path is a mountpoint of a filesystem
by issueing a btrfs-specific ioctl to it. Only in case of EINVAL it assumed
it may be a device, all other errnos just caused it fail, but some
45 matches
Mail list logo
