Chris Murphy posted on Mon, 26 Aug 2013 09:15:46 -0600 as excerpted:
I'm uncertain if autodefrag avoids this problem. It does seem like in
certain instances, like this, the file system needs to be able to prune
itself somehow, like a partial balance to consolidate data chunks and
then release
AFAICT chunk 0 is no longer special, and so it should be restriped just
like every other chunk. One reason for this change is us refusing the
relocation can lead to filesystems that can only be mounted ro, and
never rw -- see the bugzilla [1] for details. The other reason is that
device removal
On Tue, Aug 27, 2013 at 01:26:36PM +0300, Alex Lyakas wrote:
Hi Josef,
thanks for addressing this.
On Mon, Aug 5, 2013 at 6:19 PM, Josef Bacik jba...@fusionio.com wrote:
Alex Lyakas reported a bug where wait_block_group_cache_progress() would
wait
forever if a drive failed. This is
On Mon, Aug 26, 2013 at 02:53:26PM -0700, Zach Brown wrote:
With this we can
go through and convert any BUG_ON()'s that we have to catch actual
programming
mistakes to the new ASSERT() and then fix everybody else to return errors.
I like the sound of that!
--- a/fs/btrfs/ctree.h
If there's an ongoing transaction when the uuid scan kthread attempts
to create one, the kthread will block, waiting for that transaction to
finish while it's keeping locks on the tree root, and in turn the existing
transaction is waiting for those locks to be free.
The stack trace reported by
Alex Lyakas reported a bug where wait_block_group_cache_progress() would wait
forever if a drive failed. This is because we just bail out if there is an
error while trying to cache a block group, we don't update anybody who may be
waiting. So this introduces a new enum for the cache state in
On Tue, Aug 27, 2013 at 04:51:55PM +0100, Filipe David Borba Manana wrote:
If there's an ongoing transaction when the uuid scan kthread attempts
to create one, the kthread will block, waiting for that transaction to
finish while it's keeping locks on the tree root, and in turn the existing
If there's an ongoing transaction when the uuid scan kthread attempts
to create one, the kthread will block, waiting for that transaction to
finish while it's keeping locks on the tree root, and in turn the existing
transaction is waiting for those locks to be free.
The stack trace reported by
If there's an ongoing transaction when the uuid scan kthread attempts
to create one, the kthread will block, waiting for that transaction to
finish while it's keeping locks on the tree root, and in turn the existing
transaction is waiting for those locks to be free.
The stack trace reported by
Thanks for the patch Liu Bo, it has been committed as test number 10.
commit d943515bbcb8893c5d4ae21340a6022235d9e643
Author: Liu Bo bo.li@oracle.com
Date: Thu Jul 25 08:15:02 2013 +
xfstests/btrfs/010: add snapshot-aware defrag for partial extents
testcases
This is to test
Currently we will do the normal btrfs_finish_ordered_io if we invalidate a dirty
page that is part of an ordered extent but hasn't yet been submitted for IO.
The side effect of this is that when the rest of the ordered extent is completed
it will still add its extent to the file and it's csums to
On Tue, Aug 27, 2013 at 01:20:14PM -0400, Josef Bacik wrote:
Currently we will do the normal btrfs_finish_ordered_io if we invalidate a
dirty
page that is part of an ordered extent but hasn't yet been submitted for IO.
The side effect of this is that when the rest of the ordered extent is
This patch adds support for getting and changing file system
feature bits. It supports both unmounted and mounted operation via
a new set of ioctls.
Setting bits not supported by the running kernel, if the file system is
mounted, or the tools, if the file system is unmounted, can be forced with
a
There are some feature bits that require no offline setup and can
be enabled online. I've only reviewed extended irefs, but there will
probably be more.
We introduce three new ioctls:
- BTRFS_IOC_GET_SUPPORTED_FEATURES: query the kernel for supported features
- BTRFS_IOC_GET_FEATURES: query the
The macro for compat_ro had the right name but was modifying compat instead.
Signed-off-by: Jeff Mahoney je...@suse.com
---
ctree.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ctree.h b/ctree.h
index 0b0d701..8ef45f3 100644
--- a/ctree.h
+++ b/ctree.h
@@ -1912,7 +1912,7
On 8/27/13 9:47 AM, Josef Bacik wrote:
On Mon, Aug 26, 2013 at 02:53:26PM -0700, Zach Brown wrote:
With this we can
go through and convert any BUG_ON()'s that we have to catch actual
programming
mistakes to the new ASSERT() and then fix everybody else to return errors.
I like the sound of
On 8/26/13 4:56 PM, Josef Bacik wrote:
One of the complaints we get a lot is how many BUG_ON()'s we have. So to help
with this I'm introducing a kconfig option to enable/disable a new ASSERT()
mechanism much like what XFS does. This will allow us developers to still get
our nice panics but
If there's an ongoing transaction when the uuid scan kthread attempts
to create one, the kthread will block, waiting for that transaction to
finish while it's keeping locks on the tree root, and in turn the existing
transaction is waiting for those locks to be free.
The stack trace reported by
If there's an ongoing transaction when the uuid scan kthread attempts
to create one, the kthread will block, waiting for that transaction to
finish while it's keeping locks on the tree root, and in turn the existing
transaction is waiting for those locks to be free.
The stack trace reported by
On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
On 8/26/13 4:56 PM, Josef Bacik wrote:
One of the complaints we get a lot is how many BUG_ON()'s we have. So to
help
with this I'm introducing a kconfig option to enable/disable a new ASSERT()
mechanism much like what XFS
On 8/27/13 4:56 PM, Josef Bacik wrote:
On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
On 8/26/13 4:56 PM, Josef Bacik wrote:
One of the complaints we get a lot is how many BUG_ON()'s we have. So to
help
with this I'm introducing a kconfig option to enable/disable a new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/27/13 4:07 PM, Jeff Mahoney wrote:
On 8/27/13 4:56 PM, Josef Bacik wrote:
On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
On 8/26/13 4:56 PM, Josef Bacik wrote:
One of the complaints we get a lot is how many BUG_ON()'s we have.
On 8/27/13 5:21 PM, Eric Sandeen wrote:
On 8/27/13 4:07 PM, Jeff Mahoney wrote:
On 8/27/13 4:56 PM, Josef Bacik wrote:
On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
On 8/26/13 4:56 PM, Josef Bacik wrote:
One of the complaints we get a lot is how many BUG_ON()'s we have. So to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/27/13 4:25 PM, Jeff Mahoney wrote:
On 8/27/13 5:21 PM, Eric Sandeen wrote:
On 8/27/13 4:07 PM, Jeff Mahoney wrote:
On 8/27/13 4:56 PM, Josef Bacik wrote:
On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
On 8/26/13 4:56 PM, Josef
On 8/27/13 5:28 PM, Eric Sandeen wrote:
On 8/27/13 4:25 PM, Jeff Mahoney wrote:
On 8/27/13 5:21 PM, Eric Sandeen wrote:
On 8/27/13 4:07 PM, Jeff Mahoney wrote:
On 8/27/13 4:56 PM, Josef Bacik wrote:
On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
On 8/26/13 4:56 PM, Josef Bacik
Another developer just noticed this in testing; anyone have any ideas?
On 08/22/2013 05:40 PM, Sage Weil wrote:
I just noticed that there is a locking imbalance warning with sb_internal
in the transaction commit code. I believe this has only started appearing
recently (after I merged -rc5 into
On Wed, Aug 28, 2013 at 8:56 AM, Dan Mick dan.m...@inktank.com wrote:
Another developer just noticed this in testing; anyone have any ideas?
btrfs_ioctl_start_sync() calls btrfs_attach_transaction_barrier() which further
calls start_transaction() with type == TRANS_ATTACH. In
(2013/08/26 23:23), Eric Sandeen wrote:
Thanks for looking into this - how small of a device did you test?
I tried a 2MB device w/ these 2 patches and still got:
[btrfs-progs]# truncate --size=2m testfile
[btrfs-progs]# ./mkfs.btrfs testfile
WARNING! - Btrfs v0.20-rc1-360-geeeb4e9 IS
28 matches
Mail list logo
