Hi Josef,
Mon, 2013-06-24 às 12:21 -0400, Josef Bacik escreveu:
I'm not sure, I just did it and it worked fine for me. Could you file a
bugzilla at bugzilla.kernel.org and make sure the component is set to btrfs?
Also could you do the send to a file, and then receive from the file so we can
Hi Josef,
I can confirm, that I'm not able to crash it when I didn't run defrag
during other operations. So as you wish, I will place me too in
bugzilla, as I see, there is a patch available, so I will test it asap
(just need to patchcompile kernel, because I was testing debian
package before).
On Wed, Jun 26, 2013 at 12:02:51PM +0800, 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
Hi Josef,
I was trying to reproduce defrag bug to create testcase, which can
check if patch https://patchwork.kernel.org/patch/2782621/ helps to
mitigiate this bug https://bugzilla.kernel.org/show_bug.cgi?id=59451.
But I think, that I discovered another bug, or this is the cause of
it, because
In order to be able to detect the case that a filesystem is mounted
with an old kernel, add a uuid-tree-gen field like the free space
cache is doing it. It is part of the super block and written with
each commit. Old kernels do not know this field and don't update it.
Signed-off-by: Stefan
When a new subvolume or snapshot is created, a new UUID item is added
to the UUID tree. Such items are removed when the subvolume is deleted.
The ioctl to set the received subvolume UUID is also touched and will
now also add this received UUID into the UUID tree together with the
ID of the
This commit adds support to print UUID tree elements to print-tree.c.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/print-tree.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/fs/btrfs/print-tree.c b/fs/btrfs/print-tree.c
index
When the UUID tree is initially created, a task is spawned that
walks through the root tree. For each found subvolume root_item,
the uuid and received_uuid entries in the UUID tree are added.
This is such a quick operation so that in case somebody wants
to unmount the filesystem while the task is
This tree is not created by mkfs.btrfs. Therefore when a filesystem
is mounted writable and the UUID tree does not exist, this tree is
created if required. The tree is also added to the fs_info structure
and initialized, but this commit does not yet read or write UUID tree
elements.
Mapping UUIDs to subvolume IDs is an operation with a high effort
today. Today, the algorithm even has quadratic effort (based on the
number of existing subvolumes), which means, that it takes minutes
to send/receive a single subvolume if 10,000 subvolumes exist. But
even linear effort would be
If the filesystem was mounted with an old kernel that was not
aware of the UUID tree, this is detected by looking at the
uuid_tree_generation field of the superblock (similar to how
the free space cache is doing it). If a mismatch is detected
at mount time, a thread is started that does two
This should never be needed, but since all functions are there
to check and rebuild the UUID tree, a mount option is added that
allows to force this check and rebuild procedure.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
fs/btrfs/ctree.h | 1 +
fs/btrfs/disk-io.c | 3 ++-
Mapping UUIDs to subvolume IDs is an operation with a high effort
today. Today, the algorithm even has quadratic effort (based on the
number of existing subvolumes), which means, that it takes minutes
to send/receive a single subvolume if 10,000 subvolumes exist. But
even linear effort would be
Support printing these things.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
ctree.h | 15 +++
print-tree.c | 46 +++---
2 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/ctree.h b/ctree.h
index 3fe14b0..f959573
This commit changes the btrfs send/receive commands to use the
UUID tree to map UUIDs to subvolumes, and to use the root tree
to map subvolume IDs to paths. Now these tools start fast and are
independent on the number of subvolules/snapshot that exist.
Before this commit, mapping UUIDs to
The addressed issue is that Btrfs send / receive does not work as
it is today when a high number of subvolumes exist.
This commit changes the btrfs send/receive commands to use the
UUID tree to map UUIDs to subvolumes, and to use the root tree
to map subvolume IDs to paths. Now these tools start
This commit adds UUID tree lookup methods that make use of the search
ioctl. The code is based on the kernel code.
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
Makefile| 5 +--
ctree.h | 5 +++
uuid-tree.c | 104
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
btrfs-show-super.c | 2 ++
ctree.h| 5 -
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/btrfs-show-super.c b/btrfs-show-super.c
index f587f10..c815469 100644
--- a/btrfs-show-super.c
+++
Signed-off-by: Stefan Behrens sbehr...@giantdisaster.de
---
btrfs-debug-tree.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/btrfs-debug-tree.c b/btrfs-debug-tree.c
index bae7f94..c0eae9b 100644
--- a/btrfs-debug-tree.c
+++
If you use the SCRATCH_DEV_POOL for btrfs you will end up with the command line
like this
mkfs.btrfs $SCRATCH_DEV_POOL $SCRATCH_DEV
and btrfs does this thing where it makes the lowest valued device id show up in
/proc/mounts no matter which device you specify at the mount command. So in
this
Alexander Skwar alexanders.mailinglists+nospam at gmail.com writes:
Hi
On Mon, Jun 17, 2013 at 11:43 PM, Alexander Skwar
alexanders.mailinglists+nospam at gmail.com wrote:
Hello Josef
On Mon, Jun 17, 2013 at 11:21 PM, Josef Bacik jbacik at fusionio.com
wrote:
Pull down my tree
On Fri, May 03, 2013 at 07:27:21PM -0400, Dave Chinner wrote:
On Fri, May 03, 2013 at 03:15:01PM -0500, Eric Sandeen wrote:
On 5/3/13 3:11 PM, Josef Bacik wrote:
So if you have a mount command that doesn't use /etc/mtab then it will
spit out
a different device for the mounted device.
This test doesn't need the scratch dev pool and it also doesn't call
_require_scratch_dev_pool, so just kick out the scratch dev pool part of the
test. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
tests/btrfs/264 |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
After finding a super block in a device also validate its
checksum. This validation is done in the kernel but it was
missing in btrfs-progs.
The function btrfs_check_super_csum() is imported from the
file fs/btrfs/disk-io.c in the kernel source tree.
v2:
When finding the super block for a
Hi Miao,
On Mon, Jun 17, 2013 at 4:51 AM, Miao Xie mi...@cn.fujitsu.com wrote:
On sun, 16 Jun 2013 13:38:42 +0300, Alex Lyakas wrote:
Hi Miao,
On Thu, Jun 13, 2013 at 6:08 AM, Miao Xie mi...@cn.fujitsu.com wrote:
On wed, 12 Jun 2013 23:11:02 +0300, Alex Lyakas wrote:
I reviewed the
On Wed, Jun 26, 2013 at 12:18:04PM -0700, Zach Brown wrote:
$SCRATCH_DEV, so anybody who wants to just use the scratch mnt with the
scratch
dev will fail to work because we never unmount the scratch mount.
Yeah, this is annoying.
Fix this by
checking to see if the scratch dev pool
+ if (!uuid_root) {
+ WARN_ON_ONCE(1);
+ ret = -ENOENT;
+ goto out;
+ }
WARN_ON_ONCE specifically returns the condition so that you can write:
if (WARN_ON_ONCE(!uuid_root)) {
ret = -ENOENT;
goto out;
On Wed, Jun 26, 2013 at 12:02:51PM +0800, 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
ptrdiff_t diff = new_nodes - old;
ulist-root.rb_node += diff;
for (i = 0; i ulist-nnodes; i++) {
ulist-nodes[i].rb_node.rb_left += diff;
ulist-nodes[i].rb_node.rb_left += diff;
}
(rb_right
First off, thanks for an awesome file system, it is working well for
my purposes of compressing a filesystem on a small VPS. Woot!
I thought I'd call out a few things (in the hopes of spurring
improvements) I'd seen about btrfs (in case they weren't common
knowledge...):
On 06/26/2013 21:55, Zach Brown wrote:
+ if (!uuid_root) {
+ WARN_ON_ONCE(1);
+ ret = -ENOENT;
+ goto out;
+ }
WARN_ON_ONCE specifically returns the condition so that you can write:
if (WARN_ON_ONCE(!uuid_root)) {
On 6/26/13 5:47 PM, Stefan Behrens wrote:
On 06/26/2013 21:55, Zach Brown wrote:
+if (!uuid_root) {
+WARN_ON_ONCE(1);
+ret = -ENOENT;
+goto out;
+}
WARN_ON_ONCE specifically returns the condition so that you can write:
if (WARN_ON_ONCE(!uuid_root)) {
Please tell me when you are done with the full review. And please
also stop the bikeshedding.
I won't commit to a full review, and I won't try and guess which
comments you would choose to dismiss as bikeshedding. I'm free to share
what occurs to me and you're free to tell me to go jump in a
---
The matching kernel patch is here:
https://github.com/g2p/linux/tree/v3.10%2Bextent-same (rebased on 3.10, fixing
a small conflict)
Requires the btrfs-extent-same command:
- http://permalink.gmane.org/gmane.comp.file-systems.btrfs/26579
- https://github.com/markfasheh/duperemove
On Wed, Jun 26, 2013 at 08:38:21AM -0400, Josef Bacik wrote:
On Wed, Jun 26, 2013 at 12:02:51PM +0800, 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
On Wed, Jun 26, 2013 at 01:18:29PM -0700, Zach Brown wrote:
On Wed, Jun 26, 2013 at 12:02:51PM +0800, 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
On Wed, Jun 26, 2013 at 11:47:29PM +0200, Stefan Behrens wrote:
On 06/26/2013 21:55, Zach Brown wrote:
+ if (!uuid_root) {
+ WARN_ON_ONCE(1);
+ ret = -ENOENT;
+ goto out;
+ }
WARN_ON_ONCE specifically returns the condition so that you can write:
On Wed, Jun 26, 2013 at 01:18:29PM -0700, Zach Brown wrote:
On Wed, Jun 26, 2013 at 12:02:51PM +0800, 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
If you use the SCRATCH_DEV_POOL for btrfs you will end up with the command line
like this
mkfs.btrfs $SCRATCH_DEV_POOL $SCRATCH_DEV
and btrfs does this thing where it makes the lowest valued device id show up in
/proc/mounts no matter which device you specify at the mount command. So in
this
But in the krealloc() case the rb_erase() will be trying to reference
freed memmory because krealloc() frees the old pointer on success.
Yeah, I realize that you're absolutely right, but my box
didn't complain about the abused old pointers when we're not in int_nodes
case, which is
On Wed, Jun 26, 2013 at 07:23:41PM -0700, Zach Brown wrote:
But in the krealloc() case the rb_erase() will be trying to reference
freed memmory because krealloc() frees the old pointer on success.
Yeah, I realize that you're absolutely right, but my box
didn't complain about the
Reviewed-by: Anand Jain anand.j...@oracle.com
On 06/26/2013 11:52 PM, Josef Bacik wrote:
This test doesn't need the scratch dev pool and it also doesn't call
_require_scratch_dev_pool, so just kick out the scratch dev pool part of the
test. Thanks,
Signed-off-by: Josef Bacik
Per code it appears that btrfs check doesn't use the EXCL
open which means mount can be successful when the check is
running.
Thanks, Anand
--
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
43 matches
Mail list logo
