On Sat, Jul 27, 2013 at 2:12 PM, Azat Khuzhin a3at.m...@gmail.com 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
On Mon, 10 Jun 2013 09:41:39 +0200
Arne Jansen sensi...@gmx.net 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
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 getting
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 memory
在 2013-7-29，上午2:12，Kyriakos kyriakosbrastia...@gmail.com 写道：
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 =
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 ulist
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 list.bt...@jan-o-sch.net
Sent: Monday,
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
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
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
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
really
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
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
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 up the
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
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 fdman...@gmail.com
---
volumes.c |2 ++
1 file
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
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
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
Also remove unused path in extent-tree.c:finish_current_insert().
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
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
Also remove unused path in extent-tree.c:finish_current_insert().
Signed-off-by: Filipe David Borba Manana fdman...@gmail.com
---
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
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 in
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
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 fdman...@gmail.com
---
V2: added 1 more path alloc check and removed unnecessary path
allocation in
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
On mon, 29 Jul 2013 11:48:32 +0400, Azat Khuzhin wrote:
On Sat, Jul 27, 2013 at 2:12 PM, Azat Khuzhin a3at.m...@gmail.com 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
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
make
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
we
29 matches
Mail list logo
