Re: Building a brtfs filesystem 70M?

On 03/10/2014 10:47 PM, Gui Hecheng wrote: On Mon, 2014-03-10 at 20:16 -0700, Saul Wold wrote: On 03/10/2014 07:38 PM, Gui Hecheng wrote: On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote: Hi There There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get

Re: Building a brtfs filesystem 70M?

On Mon, 2014-03-10 at 23:41 -0700, Saul Wold wrote: On 03/10/2014 10:47 PM, Gui Hecheng wrote: On Mon, 2014-03-10 at 20:16 -0700, Saul Wold wrote: On 03/10/2014 07:38 PM, Gui Hecheng wrote: On Mon, 2014-03-10 at 16:25 -0700, Saul Wold wrote: Hi There There seems to be an issue if we

[PATCH] btrfs-progs: fix bug on mkfs with relative path specified

The bug accurs when exec: # mkfs.btrfs -r a relative path device (note: the path should be 'valid' correspond to your `pwd`) error msg: $ scandir for a relative path failed: No such file... Replace strdup() with realpath() to get the correct scan path. Reported-by: Saul

[PATCH 2/2] Btrfs-progs: mkfs: make sure we can deal with hard links with -r option

Steps to reproduce: # mkdir -p /tmp/test # touch /tmp/test/file # ln /tmp/test/file /tmp/test/hardlinks # mkfs.btrfs -f /dev/sda13 -r /tmp/test # btrfs check /dev/sda13 To deal with hard link, we must deal with inode with same inode id rather than increase inode id by ourselves.

[PATCH 1/2] Btrfs-progs: mkfs: don't create extent for an empty file

Steps to reproduce: # mkdir -p /tmp/test # touch /tmp/test/file # mkfs.btrfs -f /dev/sda13 -r /tmp/test # btrfs check /dev/sda13 For an empty file, don't create extent data for it. Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com --- mkfs.c | 3 +++ 1 file changed, 3 insertions(+)

Re: Testing BTRFS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 08:39 PM, Lists wrote: I'd like to begin testing BTRFS. We'd probably begin roll out in 6 months to a year if testing goes well. We're currently using CentOS6/64 everywhere, are aware of BTRFS being a Technology preview in RHEL

[PATCH v4] xfstests: add test for btrfs-progs restore feature

This is a regression test to verify that the restore feature of btrfs-progs is able to correctly recover files that have compressed extents, specially when the respective file extent items have a non-zero data offset field. This issue is fixed by the following btrfs-progs patch: Btrfs-progs:

Re: [PATCH v5 00/18] Replace btrfs_workers with kernel workqueue based btrfs_workqueue

On Fri, Feb 28, 2014 at 2:46 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Add a new btrfs_workqueue_struct which use kernel workqueue to implement most of the original btrfs_workers, to replace btrfs_workers. With this patchset, redundant workqueue codes are replaced with kernel workqueue

[PATCH 1/2] Btrfs: less fs tree lock contention when using autodefrag

When finding new extents during an autodefrag, don't do so many fs tree lookups to find an extent with a size smaller then the target treshold. Instead, after each fs tree forward search immediately unlock upper levels and process the entire leaf while holding a read lock on the leaf, since our

[PATCH 2/2] Btrfs: cache extent states in defrag code path

When locking file ranges in the inode's io_tree, cache the first extent state that belongs to the target range, so that when unlocking the range we don't need to search in the io_tree again, reducing cpu time and making and therefore holding the io_tree's lock for a shorter period. Signed-off-by:

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

On Tue, 2014-03-11 at 00:45 +0100, Lennart Poettering wrote: On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote: Well, the name is property of the admin really. There needs to be a way how the admin can label his subvolumes, with a potentially localized name. This

[PATCH] Btrfs: add missing kfree in btrfs_destroy_workqueue

Signed-off-by: Filipe David Borba Manana fdman...@gmail.com --- fs/btrfs/async-thread.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c index 00623dd..66532b8 100644 --- a/fs/btrfs/async-thread.c +++ b/fs/btrfs/async-thread.c @@ -315,6

Re: Building a brtfs filesystem 70M?

There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure: mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed. mkfs.btrfs -b 104857600 -r rootfs rootfs.btrfs Honestly, the path of least

Re: Kernel BUG: btrfs send - Incremental backup

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/08/2014 02:35 AM, Swâmi Petaramesh wrote: Hi there, I tried to perform an incremental backup as described in

[PATCH v2] Btrfs: return EPERM when deleting a default subvolume

The error message is confusing: # btrfs sub delete /mnt/mysub/ Delete subvolume '/mnt/mysub' ERROR: cannot delete '/mnt/mysub' - Directory not empty The error message does not make sense to me: It's not about deleting a directory but it's a subvolume, and it doesn't matter if the subvolume is

Re: Testing BTRFS

On 3/10/14, 8:02 PM, Avi Miller wrote: On 11 Mar 2014, at 11:39 am, Lists li...@benjamindsmith.com wrote: Is there a recommended way to do this? Is it anywhere as easy as ZFSonLinux yum install? Oracle Linux 6 with the Unbreakable Enterprise Kernel Release 2 or Release 3 has

Re: Testing BTRFS

Hey, On 12 Mar 2014, at 6:08 am, Eric Sandeen sand...@redhat.com wrote: If we're plugging distros... I can also tell you that you can install upcoming RHEL7 on btrfs if you like, and it has a very up-to-date btrfs codebase. Ditto for OL7, for obvious reasons. :) Indeed, testing

warn at fs/btrfs/extent-tree.c:5748 __btrfs_free_extent+0x9ce/0xa20

Hey, Is this something you guys have seen before? This is from v3.13-rc2. kernel: [49432.696440] WARNING: CPU: 3 PID: 26411 at /srv/autobuild-ceph/gitbuilder.git/build/fs/btrfs/extent-tree.c:5748 __btrfs_free_extent+0x9ce/0xa20 [btrfs]() kernel: [49432.710128] Modules linked in: arc4(F)

Re: Building a brtfs filesystem 70M?

On Tue, 11 Mar 2014 09:37:00 -0700, Zach Brown wrote: There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure: mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent: Assertion `!(ret)' failed. mkfs.btrfs -b 104857600 -r

Re: Building a brtfs filesystem 70M?

On 03/11/2014 06:10 PM, quwen...@cn.fujitsu.com wrote: On Tue, 11 Mar 2014 09:37:00 -0700, Zach Brown wrote: There seems to be an issue if we try to build a btrfs based FS that is less than 70M, we get the following assertion failure: mkfs.btrfs: extent-tree.c:2682: btrfs_reserve_extent:

Re: [PATCH] Btrfs: add missing kfree in btrfs_destroy_workqueue

On Tue, 11 Mar 2014 14:31:44 +, Filipe David Borba Manana wrote: Signed-off-by: Filipe David Borba Manana fdman...@gmail.com --- fs/btrfs/async-thread.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c index 00623dd..66532b8 100644

[PATCH 1/2 v2] Btrfs: less fs tree lock contention when using autodefrag

When finding new extents during an autodefrag, don't do so many fs tree lookups to find an extent with a size smaller then the target treshold. Instead, after each fs tree forward search immediately unlock upper levels and process the entire leaf while holding a read lock on the leaf, since our