Only in the case of different root_id or different object_id, check_shared
identified extent as the shared. However, If a extent was referred by
different offset of same file, it should also be identified as shared.
In addition, check_shared's loop scale is at least n^3, so if a extent
has too
At 06/01/2016 12:23 AM, David Sterba wrote:
On Tue, May 31, 2016 at 03:27:42PM +0800, luke wrote:
+static void ref_root_fini(struct ref_root *ref_tree)
+{
+ struct ref_node *node;
+ struct rb_node *next;
+
+ while ((next = rb_first(_tree->rb_root)) != NULL) {
+
On Wed, Jun 01, 2016 at 09:31:14AM +0800, Qu Wenruo wrote:
> Thanks for the test case.
> It would be better if you could submit a test case for it.
Yeah I'll handle this.
> Reproduced the problem. I'll track it down.
> Seems to be related with metadata.
Thanks, please CC me on any patches.
On Thu, May 05, 2016 at 12:23:49AM -0400, Zygo Blaxell wrote:
> During a mount, we start the cleaner kthread first because the transaction
> kthread wants to wake up the cleaner kthread. We start the transaction
> kthread next because everything in btrfs wants transactions. We do reloc
>
At 06/01/2016 03:51 AM, Mark Fasheh wrote:
Thanks for this test.
On Tue, May 31, 2016 at 10:03:54AM +0800, Lu Fengqi wrote:
+echo "Start balance" >>$seqres.full
+_btrfs_stress_balance -d $SCRATCH_MNT >/dev/null 2>&1 &
+balance_pid=$!
+
+# 30s is enough to trigger bug
+sleep
At 06/01/2016 12:01 AM, David Sterba wrote:
On Tue, May 31, 2016 at 03:14:25PM +0800, luke wrote:
@@ -68,6 +68,12 @@ struct meta_cluster {
struct fs_chunk {
u64 logical;
u64 physical;
+ /* physical_dup only store additonal physical for BTRFS_BLOCK_GROUP_DUP
+*
Signed-off-by: Lu Fengqi
---
btrfs-image.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/btrfs-image.c b/btrfs-image.c
index d121951..7c2fa94 100644
--- a/btrfs-image.c
+++ b/btrfs-image.c
@@ -1757,6 +1757,7 @@ static void *restore_worker(void *data)
New convert framework uses new and simpler chunk layout, while the cost
is the more complex superblock range migration logical, compared to old
convert.
Enhance the convert test script to create file which will takes up 2nd
backup superblock space, to ensure the superblock migration is working
as
At 06/01/2016 12:50 AM, David Sterba wrote:
On Tue, May 31, 2016 at 03:51:13PM +0800, Qu Wenruo wrote:
When a ext2 fs filled with a 57M file, it's possible that convert fails
with assert in add_merge_cache_extent().
The problem is that the ext2 used space just takes some of the second
At 06/01/2016 08:50 AM, Mark Fasheh wrote:
On Mon, May 30, 2016 at 03:48:14PM +0800, Qu Wenruo wrote:
Mark Fasheh wrote on 2016/05/26 17:18 -0700:
The btrfs balance operation is significantly slower when qgroups are
enabled. To the best of my knowledge, a balance shouldn't have an effect
At 06/01/2016 12:15 AM, David Sterba wrote:
On Tue, May 31, 2016 at 11:08:39AM +0800, luke wrote:
+};
+
+/* dynamically allocate and initialize a ref_root */
+static struct ref_root *ref_root_alloc(gfp_t gfp_mask)
+{
+ struct ref_root *ref_tree;
+
+ ref_tree =
On Mon, May 30, 2016 at 03:48:14PM +0800, Qu Wenruo wrote:
>
>
> Mark Fasheh wrote on 2016/05/26 17:18 -0700:
> >The btrfs balance operation is significantly slower when qgroups are
> >enabled. To the best of my knowledge, a balance shouldn't have an effect on
> >qgroups counts (extents are not
From: Jeff Mahoney
Since several architectures support hardware-accelerated crc32c
calculation, it would be nice to confirm that btrfs is actually using it.
We can see an elevated use count for the module, but it doesn't actually
show who the users are. This patch simply prints
On 2016/06/01 6:53, al wrote:
Please can someone run:
# ls -l /var/lib/ | grep btrfs
for me (and post to directly or via list as they think fit).
$ ls -l /var/lib | grep btrfs
drwxr-xr-x 1 root root 196 May 18 10:34 btrfs
On Fri, Mar 25, 2016 at 07:01:33PM -0700, Ashish Samant wrote:
> Remove unnecessary checks in compress_file_range().
>
> Signed-off-by: Ashish Samant
I was looking for unmerged patches and found this one, now queued for
4.8.
--
To unsubscribe from this list: send the
Please can someone run:
# ls -l /var/lib/ | grep btrfs
for me (and post to directly or via list as they think fit).
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, May 31, 2016 at 04:41:55PM -0400, Jeff Mahoney wrote:
> Hi all -
>
> Strace 4.12 was tagged for release today and it supports decoding of
> btrfs ioctls. I'd like to propose a requirement that future ioctl
> additions come with a patch to strace as well so we don't get out of sync.
>
>
Hi all -
Strace 4.12 was tagged for release today and it supports decoding of
btrfs ioctls. I'd like to propose a requirement that future ioctl
additions come with a patch to strace as well so we don't get out of sync.
I wrote the decoding to help with some issues some of our developers
were
On Fri, May 27, 2016 at 01:03:04PM -0400, Josef Bacik wrote:
> This is just a screwup for developers, so change it to an ASSERT() so
> developers
> notice when things go wrong and deal with the error appropriately if ASSERT()
> isn't enabled. Thanks,
>
> Signed-off-by: Josef Bacik
Thanks for this test.
On Tue, May 31, 2016 at 10:03:54AM +0800, Lu Fengqi wrote:
> +echo "Start balance" >>$seqres.full
> +_btrfs_stress_balance -d $SCRATCH_MNT >/dev/null 2>&1 &
> +balance_pid=$!
> +
> +# 30s is enough to trigger bug
> +sleep $((30*$TIME_FACTOR))
> +kill $fsstress_pid
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Chris,
since you are using a recent LTS kernel on your centos/rockstor, i guess
the kernel errors might help to find some bugs here.
can you give the devs the errors from your logs?
additionally basic info on your raid settings would be nice to, but
which specific details the devs should ask
On Tue, May 31, 2016 at 04:49:33PM +0800, Qu Wenruo wrote:
> New convert has several bugs with backup superblock migration
>
> 1) Backup superblocks are not migrated due to bad judgement
>Two wrong judgement cause backup superblocks are not migrated at all
>
> 2) Converted ext* image doesn't
On Tue, May 31, 2016 at 03:51:13PM +0800, Qu Wenruo wrote:
> When a ext2 fs filled with a 57M file, it's possible that convert fails
> with assert in add_merge_cache_extent().
>
> The problem is that the ext2 used space just takes some of the second
> superblock.
> And due to a bug in reserving
On Tue, May 31, 2016 at 10:46:00AM +0800, Qu Wenruo wrote:
> For new btrfs-convert, it's less restrict for metadata chunk allocation.
> While the may_rollback() function is still following the restrict 1:1
> mapping check for all chunks, it will not allow some new convert image
> to be rolled
If we're running against a old version of xfsprogs that lacks some of
the structures that the golden output knows about, copy the structure
size definition from the golden output to the program output. This
way we can check for structure size mutations on old xfsprogs without
generating false
On Tue, May 31, 2016 at 05:51:09AM -0700, Christoph Hellwig wrote:
> Looks fine, but can't we also remove the workaround at the end of the
> the test as well?
Oh, heh, yes, those can go. The whitespace is wrong on them anyway.
--D
>
> ___
> xfs
On Tue, 31 May 2016, Filipe Manana wrote:
On Mon, May 30, 2016 at 7:48 PM, Chris Johnson wrote:
I have a RAID6 array that had a failed HDD. The drive failed
completely and has been removed from the system. I'm running a 'device
replace' operation with a new disk. The
On 05/30/2016 11:19 AM, fdman...@kernel.org wrote:
From: Filipe Manana
While we are finishing a device replace operation, we can make a discard
operation (fs mounted with -o discard) do an invalid memory access like
the one reported by the following trace:
[ 3206.384654]
On 05/30/2016 11:19 AM, fdman...@kernel.org wrote:
From: Filipe Manana
While we are finishing a device replace operation we can have a concurrent
task trying to do a read repair operation, in which case it will call
btrfs_map_block() to get a struct btrfs_bio which can have
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine,
Reviewed-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Looks fine, but can't we also remove the workaround at the end of the
the test as well?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 2016-05-26 18:12, Graham Cobb wrote:
On 19/05/16 02:33, Qu Wenruo wrote:
Graham Cobb wrote on 2016/05/18 14:29 +0100:
A while ago I had a "no space" problem (despite fi df, fi show and fi
usage all agreeing I had over 1TB free). But this email isn't about
that.
As part of fixing that
On 2016-05-29 16:45, Ferry Toth wrote:
Op Sun, 29 May 2016 12:33:06 -0600, schreef Chris Murphy:
On Sun, May 29, 2016 at 12:03 PM, Holger Hoffstätte
wrote:
On 05/29/16 19:53, Chris Murphy wrote:
But I'm skeptical of bcache using a hidden area historically for
On 2016-05-27 15:47, Nicholas D Steeves wrote:
On 16 May 2016 at 08:39, Austin S. Hemmelgarn wrote:
On 2016-05-16 08:14, Richard W.M. Jones wrote:
It would be really helpful if the btrfs tools had a machine-readable
output.
With machine-readable output, there'd be a
At 05/31/2016 05:18 PM, Filipe Manana wrote:
On Tue, May 31, 2016 at 10:08 AM, luke wrote:
At 05/31/2016 03:39 PM, Filipe Manana wrote:
On Tue, May 31, 2016 at 3:03 AM, Lu Fengqi wrote:
Test if qgroup can handle de-reference
On Tue, May 31, 2016 at 10:08 AM, luke wrote:
>
>
>
>
> At 05/31/2016 03:39 PM, Filipe Manana wrote:
>
> On Tue, May 31, 2016 at 3:03 AM, Lu Fengqi wrote:
>
> Test if qgroup can handle de-reference reallocation.
>
> What is "de-reference
New convert has several bugs with backup superblock migration
1) Backup superblocks are not migrated due to bad judgement
Two wrong judgement cause backup superblocks are not migrated at all
2) Converted ext* image doesn't keep hole for backup superblocks
Since we are creating file extents
When a ext2 fs filled with a 57M file, it's possible that convert fails
with assert in add_merge_cache_extent().
The problem is that the ext2 used space just takes some of the second
superblock.
And due to a bug in reserving superblock space, it corrupted used space
tree and cause assert.
Fix in
On Mon, May 30, 2016 at 7:48 PM, Chris Johnson wrote:
> I have a RAID6 array that had a failed HDD. The drive failed
> completely and has been removed from the system. I'm running a 'device
> replace' operation with a new disk. The array is ~20TB so this will
> take a few
On Tue, May 31, 2016 at 3:03 AM, Lu Fengqi wrote:
> Test if qgroup can handle de-reference reallocation.
What is "de-reference reallocation"?
> Although current
> qgroup can handle it, we still need to prevent any regression which may
> break current qgroup.
>
>
42 matches
Mail list logo