On Sat, Jul 27, 2013 at 2:12 PM, Azat Khuzhin wrote:
> Replace list_for_each_entry() by list_for_each_entry_safe() in
> __btrfs_close_devices()
>
> There is another place that delete items lock_stripe_add(), but there we
> don't need safe version, because after deleting we exit from loop.
>
> Sign
On Mon, 10 Jun 2013 09:41:39 +0200
Arne Jansen wrote:
> > Now, my questions:
> >
> > - what do both 104882176 104882176 numbers represent?
>
> The first number represents the amount of data in that subvolume,
> regardless whether that data is shared with other subvolumes or
> not.
> The second
Hi BJ,
[original message rewrapped]
On Thu, July 25, 2013 at 18:32 (+0200), BJ Quinn wrote:
> (Apologies for the double post -- forgot to send as plain text the first time
> around, so the list rejected it.)
>
> I see that there's now a btrfs send / receive and I've tried using it, but
> I'm get
On Fri, June 28, 2013 at 06:37 (+0200), 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 memo
在 2013-7-29，上午2:12，Kyriakos 写道：
> Just tried it as you said with the -v option enabled
> This is my output:
>
> http://bpaste.net/show/118112/
>
>
This is a *long* email, and seems that btrfs list refuse it.
> Device extent: devid = 1, start = 1667558801408, len = 1073741824,
> chunk offset
On Mon, Jul 29, 2013 at 10:23:34AM +0200, Jan Schmidt wrote:
> On Fri, June 28, 2013 at 06:37 (+0200), 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 u
This patch removes the io_tree argument for extent_clear_unlock_delalloc since
we always use &BTRFS_I(inode)->io_tree, and it separates out the extent tree
operations from the page operations. This way we just pass in the extent bits
we want to clear and then pass in the operations we want done to
Thanks for the response! Not sure I want to roll a custom kernel on this
particular system. Any idea on when it might make it to 3.10 stable or
3.11? Or should I just revert back to 3.9?
Thanks!
-BJ
- Original Message -
From: "Jan Schmidt"
Sent: Monday, July 29, 2013 3:21:51 AM
Hello,
I am willing to perform QA on online data deduplication. From where
can i download the patches?
--
Thanks,
Hemanth Kumar H C
--
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.k
So df in btrfs is tricky at best, and relying on it for accurate information is
not great, but it's the best way to verify this test. So we need to add another
sync to make sure the pinned blocks are all freed up and the df space is really
really accurate, otherwise we end up with this test failli
First of all we no longer set EXTENT_DIRTY when we dirty an extent so this patch
removes the clearing of EXTENT_DIRTY since it confuses me. This patch also adds
clearing EXTENT_DEFRAG and also doing EXTENT_DO_ACCOUNTING when we have errors.
This is because if we are clearing delalloc without addin
On 7/29/13 12:21 PM, Josef Bacik wrote:
> So df in btrfs is tricky at best, and relying on it for accurate information
> is
> not great, but it's the best way to verify this test. So we need to add
> another
> sync to make sure the pinned blocks are all freed up and the df space is
> really
> r
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. :(
I'm not sure what bug this is trying to test; if you need 2 syncs for global
space stats to accurately re
After reading all device items from the chunk tree, don't
exit the loop and then navigate down the tree again to find
the chunk items. Instead just read all device items and
chunk items with a single tree search. This is possible
because all device items are found before any chunk item in
the chunk
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 u
After reading all device items from the chunk tree, don't
exit the loop and then navigate down the tree again to find
the chunk items. Instead just read all device items and
chunk items with a single tree search. This is possible
because all device items are found before any chunk item in
the chunk
If the chunk tree search failed in volumes.c:btrfs_read_chunk_tree()
return immediately, rather than looping and use the invalid contents
of the path structure, causing weird errors/crash at run time.
Signed-off-by: Filipe David Borba Manana
---
volumes.c |2 ++
1 file changed, 2 insertions(
So df in btrfs is tricky at best, and relying on it for accurate information is
not great, but it's the best way to verify this test. To get around btrfs being
inconsistent sometimes just use _within_tolerance to check our new df value to
make sure that our truncate did something. With this patch
First of all we no longer set EXTENT_DIRTY when we dirty an extent so this patch
removes the clearing of EXTENT_DIRTY since it confuses me. This patch also adds
clearing EXTENT_DEFRAG and also doing EXTENT_DO_ACCOUNTING when we have errors.
This is because if we are clearing delalloc without addin
Unrecoverable?
I know i cant mount and have access but my data are still there intact
( as i was using them till the reboot) i shouldn't be able to
extract/recover them to another disc? With any magic command without
mounting?
Any other solutions?
http://bpaste.net/show/118112/
On 29 July 2013 15
Also remove unused path in extent-tree.c:finish_current_insert().
Signed-off-by: Filipe David Borba Manana
---
V2: added 1 more path alloc check and removed unnecessary path
allocation in extent-tree.c:finish_current_insert().
extent-tree.c |8
1 file changed, 4 insertions(+),
Also remove unused path in extent-tree.c:finish_current_insert().
Signed-off-by: Filipe David Borba Manana
---
V2: added 1 more path alloc check and removed unnecessary path
allocation in extent-tree.c:finish_current_insert().
V3: added missing path alloc checks to dir-item.c, file-item.c
On Mon, Jul 29, 2013 at 09:05:42PM +0530, Hemanth Kumar wrote:
> Hello,
> I am willing to perform QA on online data deduplication. From where
> can i download the patches?
Hi Hemanth Kumar H C,
I really appreciate this :)
Right now I'm planning v5 version patch set, which will come out probably
On mon, 29 Jul 2013 19:22:34 +0100, Filipe David Borba Manana wrote:
> After reading all device items from the chunk tree, don't
> exit the loop and then navigate down the tree again to find
> the chunk items. Instead just read all device items and
> chunk items with a single tree search. This is p
On mon, 29 Jul 2013 23:37:19 +0100, Filipe David Borba Manana wrote:
> Also remove unused path in extent-tree.c:finish_current_insert().
>
> Signed-off-by: Filipe David Borba Manana
> ---
>
> V2: added 1 more path alloc check and removed unnecessary path
> allocation in extent-tree.c:fi
On mon, 29 Jul 2013 19:35:49 +0100, Filipe David Borba Manana wrote:
> After reading all device items from the chunk tree, don't
> exit the loop and then navigate down the tree again to find
> the chunk items. Instead just read all device items and
> chunk items with a single tree search. This is p
On mon, 29 Jul 2013 11:48:32 +0400, Azat Khuzhin wrote:
> On Sat, Jul 27, 2013 at 2:12 PM, Azat Khuzhin wrote:
>> Replace list_for_each_entry() by list_for_each_entry_safe() in
>> __btrfs_close_devices()
>>
>> There is another place that delete items lock_stripe_add(), but there we
>> don't need s
On 07/30/2013 02:55 AM, Josef Bacik wrote:
> So df in btrfs is tricky at best, and relying on it for accurate information
> is
> not great, but it's the best way to verify this test. To get around btrfs
> being
> inconsistent sometimes just use _within_tolerance to check our new df value to
> m
On mon, 29 Jul 2013 11:23:00 -0400, Josef Bacik wrote:
> This patch removes the io_tree argument for extent_clear_unlock_delalloc since
> we always use &BTRFS_I(inode)->io_tree, and it separates out the extent tree
> operations from the page operations. This way we just pass in the extent bits
> w
On mon, 29 Jul 2013 13:24:22 -0400, Josef Bacik wrote:
> First of all we no longer set EXTENT_DIRTY when we dirty an extent so this
> patch
> removes the clearing of EXTENT_DIRTY since it confuses me. This patch also
> adds
> clearing EXTENT_DEFRAG and also doing EXTENT_DO_ACCOUNTING when we hav
30 matches
Mail list logo
