I created two pools, one xfs one btrfs, default formatting and mount options. I
then created a qcow2 file on each using virt-manager, also using default
options. And default caching (whatever that is, I think it's writethrough but
don't hold me to it).
I then installed Windows 7 (not
I tried the same routine on 32GB usb sticks. Same exact problems. 32GB
seems a bit much for a --mixed btrfs.
I haven't tried ssd_spread, maybe it's beneficial. However, as I wrote
above, disabling autodefrag gets rid completely of the INFO: hung
task messages but even though the kernel doesn't
On Sep 3, 2014, at 12:01 AM, Chris Murphy li...@colorremedies.com wrote:
I created two pools, one xfs one btrfs, default formatting and mount options.
I then created a qcow2 file on each using virt-manager, also using default
options. And default caching (whatever that is, I think it's
All the metadata in the seed devices has the same fsid as the fsid
of the seed filesystem which is on the seed device, so we should check
them by the current filesystem. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
Reviewed-by: David Sterba dste...@suse.cz
---
Changelog v1 - v2:
- Use
The io error might happen during writing out the device stats, and the
device stats information and dirty flag would be update at that time,
but the current code didn't consider this case, just clear the dirty
flag, it would cause that we forgot to write out the new device stats
information. Fix
On Wed, Sep 03, 2014 at 04:53:39AM +, Duncan wrote:
Hugo Mills posted on Tue, 02 Sep 2014 13:13:49 +0100 as excerpted:
On Tue, Sep 02, 2014 at 12:05:33PM +, Holger Hoffstätte wrote:
So where does the confusing initial display come from? [I] don't
remember ever seeing this with
Hugo Mills posted on Wed, 03 Sep 2014 08:33:05 +0100 as excerpted:
On Wed, Sep 03, 2014 at 04:53:39AM +, Duncan wrote:
Hugo Mills posted on Tue, 02 Sep 2014 13:13:49 +0100 as excerpted:
[A] btrfs fi df on a new filesystem always seems to have those extra
unused single profile lines.
On Tue, 2 Sep 2014 09:05:15 -0400, Chris Mason wrote:
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 08e65e9..56b1546 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -698,7 +719,12 @@ static void end_workqueue_bio(struct bio *bio, int
err)
fs_info =
On Wed, Sep 03, 2014 at 08:03:51AM +0200, john terragon wrote:
I tried the same routine on 32GB usb sticks. Same exact problems. 32GB
seems a bit much for a --mixed btrfs.
I haven't tried ssd_spread, maybe it's beneficial. However, as I wrote
above, disabling autodefrag gets rid completely of
Hi,
I have a btrfs partition which throw kernel BUG, even with linux
3.17-rc3 (I tried 3.14.16, 3.16.1 and 3.17-rc3 kernels) :
[ 45.058466] [ cut here ]
[ 45.058539] kernel BUG at fs/btrfs/relocation.c:1065!
[ 45.058578] invalid opcode: [#1] SMP
[ 45.058655]
Hi,
maybe someone can enlighten me. I am doing btrfs send receive with full
snapshots and incremental updates.
It basically looks like this:
vol-0 and vol-1 are full subvolume image sends.
inc-1 and inc-2 are incremental images with:
# btrfs send -f inc-1 -p vol vol'
# btrfs send -f inc-2 -p
On 09/02/2014 09:31 PM, john terragon wrote:
Rsync finished. FWIW in the end it reported an average speed of about
900K/sec. Without autodefrag there have been no messages about hung
kworkers even though rsync seemingly keeps getting hung for several
minutes throughout the whole execution.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/dev-replace.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index a85b5f5..10dfb41 100644
--- a/fs/btrfs/dev-replace.c
+++ b/fs/btrfs/dev-replace.c
@@ -550,7 +550,6 @@ static int
During removing a device, we have modified free_chunk_space when we
shrink the device, so we needn't assign a new value to it after
the device shrink. Fix it.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 5 -
1 file changed, 5 deletions(-)
diff --git
The member variants - num_can_discard - of fs_devices structure
are set, but no one use them to do anything. so remove them.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 16 ++--
fs/btrfs/volumes.h | 1 -
2 files changed, 2 insertions(+), 15 deletions(-)
Some code in btrfs_get_bdev_and_sb will be re-used by the other function later,
so restructure btrfs_get_bdev_and_sb and pick up those code to make a new
function.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 66 +-
1
We didn't protect the assignment of the target device, it might cause the
problem that the super block update was skipped because we might find wrong
size of the target device during the assignment. Fix it by moving the
assignment sentences into the initialization function of the target device.
Some code in btrfs_scan_one_device will be re-used by the other function later,
so restructure btrfs_scan_one_device and pick up those code to make a new
function.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 57 +++---
1
When we open a seed filesystem, if the degraded mount option is set, we
continue to
mount the fs if we don't find some devices in the seed filesystem. But we
should stop
mounting if other errors happen. Fix it
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 2 +-
1 file
The problem is:
Task0(device scan task) Task1(device replace task)
scan_one_device()
mutex_lock(uuid_mutex)
device = find_device()
mutex_lock(device_list_mutex)
lock_chunk()
We should update free_chunk_space in time when we allocate a new chunk,
not when we deal with the pending device update and block group insertion,
because we need the real free_chunk_space data to calculate the reserved
space, if we don't update it in time, we would consider the disk space which
We will implement the function that the filesystem scan all the devices
in the system and build the device set for btrfs. In this case, we needn't
get btrfs_fs_devices when adding a device into list. This patch changes
device_add_list and implement this feature.
Signed-off-by: Miao Xie
We didn't protect the system chunk array when we added a new
system chunk into it, it would cause the array be corrupted
if someone remove/add some system chunk into array at the same
time. Fix it by chunk lock.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 7 ++-
1
This patchset implements device list automatic building function. As we
know, currently we need scan the devices to build device list by a user tool
before mounting the filesystem, especially mount the filesystem after
we re-install btrfs module. It is not convenient. This patchset can improve
When we get the fs information, we forgot to acquire the mutex of device list,
it might cause the problem we might access a device that was removed. Fix
it by acquiring the device list mutex.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/super.c | 8 +++-
1 file changed, 7
-total_bytes,-disk_total_bytes,-bytes_used is protected by chunk
lock when we change them, but sometimes we read them without any lock,
and we might get unexpected value. We fix this problem like inode's
i_size.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/dev-replace.c | 15
There were several problems about chunk mutex usage:
- Lock chunk mutex when updating metadata. It would cause the nested
deadlock because updating metadata might need allocate new chunks
that need acquire chunk mutex. We remove chunk mutex at this case,
because b-tree lock and other lock
total_size will be changed when resizing a device, and disk_total_size
will be changed if resizing is successful. Meanwhile, the on-disk super
blocks of the previous transaction might not be updated. Considering
the consistency of the metadata in the previous transaction, We should
use the size in
We should update device-bytes_used in the lock context of
chunk_mutex, or we would get wrong data.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index
device-bytes_used will be changed when allocating a new chunk, and
disk_total_size will be changed if resizing is successful.
Meanwhile, the on-disk super blocks of the previous transaction
might not be updated. Considering the consistency of the metadata
in the previous transaction, We should use
rw_devices counter is often used to tune the profile when doing chunk
allocation,
so we should modify it under the chunk_mutex context to avoid getting wrong
chunk profile.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/volumes.c | 4 ++--
1 file changed, 2 insertions(+), 2
We can build a new filesystem based a seed filesystem, and we need clone
the fs devices when we open the new filesystem. But someone might clear
the seed flag of the seed filesystem, then mount that filesystem and
remove some device. If we mount the new filesystem, we might access
a device list
The original code need scan the devices and build the fs device list by the user
tool by udev or users' selves. It is flexible. But if someone re-install the
filesystem module, and forget to scan the devices by himself, or we plug some
devices with btrfs, but udev thread is blocked and doesn't
Btrfs can make filesystem cross several disks/partitions, in order to
load all the disks/partitions which belong to the same filesystem, we
need scan the system and find all the devices, and then register them
into the kernel. Currently, we do it by user tool. But if we forget to
do it, we can not
For a missing device, we don't know it belong to which fs before we read its
fsid from the chunk tree. So we add them into the current fs device list at
first.
When we get its fsid, we should move them to their own fs device list.
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/dev-replace.c | 3 +--
fs/btrfs/volumes.c | 19 +++
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/fs/btrfs/dev-replace.c b/fs/btrfs/dev-replace.c
index e9cbbdb..6f662b3 100644
---
I wasn't sure what you meant with wherever you mkfs btrfs so I dd'd
all the three possible cases:
1) here's the dmcrypt device on which I mkfs.btrfs
2097152000 bytes (2.1 GB) copied, 487.265 s, 4.3 MB/s
2) here's the partition of the usb stick (which has another partition
containing /boot)
On Sep 3, 2014, at 8:11 AM, john terragon jterra...@gmail.com wrote:
It's a usb2 device but doesn't it seem kind of slow?
Not atypical, I have one that's the same, and another that's ~21MB/s, both are
USB 2.
[Certain older Apple Mac firmware boot faster with the slow stick than the fast
It is interesting that for me the number of extents before and after
bcache are essentially the same.
The lesson here for me there is that the fragmentation of a btrfs
nodatacow file is not mitigated by bcache. There seems to be nothing I
can do to prevent that fragmentation, and may in fact be
At a 32 bit stable Gentoo Linux I do have 2 BTRFS file systems :
$ mount | grep btrfs
/var/lib/portage.fs on /usr/portage type btrfs (rw,noatime,compress=lzo)
/var/lib/pkg.fs on /var/db/pkg type btrfs (rw,noatime,compress=lzo)
holding a lot of small Gentoo-package-Manager-related files. The
Got the following with 3.17-rc3 and running balance (had to power cycle
after that):
[ 1329.952600] [ cut here ]
[ 1329.952671] WARNING: CPU: 7 PID: 3106 at fs/btrfs/extent-tree.c:876
btrfs_lookup_extent_info+0x377/0x3eb [btrfs]()
[ 1329.952726] Modules linked in:
Hi Richard,
It is interesting that for me the number of extents before and after
bcache are essentially the same.
The lesson here for me there is that the fragmentation of a btrfs
nodatacow file is not mitigated by bcache. There seems to be nothing I
can do to prevent that fragmentation,
Hi everyone,
For 3.16, please pull these into stable, I've cherry picked and tested
them here. For 3.15 and earlier there are a few conflicts, so I'll make
a git tree with things to pull.
8d875f95da43c6a8f18f77869f2ef26e9594fecc v3.15+
38c1c2e44bacb37efd68b90b3f70386a8ee370ee v3.11+
On Tue, Aug 19, 2014 at 01:10:45PM +0200, David Sterba wrote:
Hi stable team,
please add the following patches to stable trees.
Patch #3 applies to all currently live stables, a 7 years old bug. I've
briefly reviewed all 3 patches against 3.10/12/14/16 (ie. 3.4 skips #1
and #2).
On Wed, Sep 03, 2014 at 04:50:47PM -0400, Chris Mason wrote:
Hi everyone,
For 3.16, please pull these into stable, I've cherry picked and tested
them here. For 3.15 and earlier there are a few conflicts, so I'll make
a git tree with things to pull.
Am Mittwoch, 3. September 2014, 19:17:17 schrieben Sie:
At a 32 bit stable Gentoo Linux I do have 2 BTRFS file systems :
$ mount | grep btrfs
/var/lib/portage.fs on /usr/portage type btrfs (rw,noatime,compress=lzo)
/var/lib/pkg.fs on /var/db/pkg type btrfs (rw,noatime,compress=lzo)
Martin Steigerwald posted on Thu, 04 Sep 2014 00:02:03 +0200 as excerpted:
Am Mittwoch, 3. September 2014, 19:17:17 schrieben Sie:
At a 32 bit stable Gentoo Linux I do have 2 BTRFS file systems :
$ mount | grep btrfs /var/lib/portage.fs on /usr/portage type btrfs
(rw,noatime,compress=lzo)
On Wed, 03 Sep 2014 16:50:47 -0400, Chris Mason wrote:
Hi everyone,
For 3.16, please pull these into stable, I've cherry picked and tested
them here. For 3.15 and earlier there are a few conflicts, so I'll make
a git tree with things to pull.
8d875f95da43c6a8f18f77869f2ef26e9594fecc
On 09/03/2014 07:36 PM, Holger Hoffstätte wrote:
On Wed, 03 Sep 2014 16:50:47 -0400, Chris Mason wrote:
Hi everyone,
For 3.16, please pull these into stable, I've cherry picked and tested
them here. For 3.15 and earlier there are a few conflicts, so I'll make
a git tree with things to
Original find_mount_root() will use the first mount point match and
return it.
It was OK until the following commit, which will also check the fstype:
de22c28ef31d9721606ba059 btrfs-progs: Check fstype in find_mount_root()
With fstype check, we should check the last match, not only the first
one.
On Mon, 2014-09-01 at 15:25 +, Zooko Wilcox-OHearn wrote:
I'm more than happy to try out patches and even focus my own brain on
diagnosing it, if I can. I'm hoping to regain access to some of my
files on my btrfs partition, and also I would enjoy helping get this
improved. :-)
So if you
The btrfs_free_path calls btrfs_release_path internally.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
disk-io.c | 1 -
file-item.c | 1 -
inode-map.c | 2 --
3 files changed, 4 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 9e44f10..0f9f374 100644
--- a/disk-io.c
+++
Before this patch, you could see the following after exec restore
# :too few arguments
The tool name btrfs restore is missing.
The @set_argv0() function is introduced by:
commit a184abc70f7b1468e6036ab576f1587ee0574668
btrfs-progs: move the check_argc_* functions into
Hi.
When I traverse one of my btrfs, for example with a simple find /, I
get the following in kmsg
BTRFS critical (device dm-0): invalid dir item name len: 45389
The message appears just one time (so I guess it involves just one
file/dir). dm-0 is the first dmcrypt device of a pair on which I
54 matches
Mail list logo
