On Fri, May 10, 2013 at 01:30 (+0200), Kai Krakow wrote:
Jan Schmidt list.bt...@jan-o-sch.net schrieb:
Apparently, it's not fixed. The system does not freeze now but it threw
multiple backtraces right in front of my Xorg session. The backtraces
look a little bit different now. Here's what I
On 09.05.2013 17:14, Remco Hosman - Yerf IT wrote:
kernel: 3.9.0
btrfs-progs: pulled from git this morning
Trying to receive a 5gig send file. the first bit is fast, doing 10 -
50MB/sec.
then it slows down. cpu usage is 50% (dual core machine).
when i do a strace, it looks like this,
On May 10, 2013, at 9:27 AM, Arne Jansen sensi...@gmx.net wrote:
On 09.05.2013 17:14, Remco Hosman - Yerf IT wrote:
kernel: 3.9.0
btrfs-progs: pulled from git this morning
Trying to receive a 5gig send file. the first bit is fast, doing 10 -
50MB/sec.
then it slows down. cpu usage is
Hi,
I am looking for a file-system which is able to provide continuous
snapshotting like some log-structured file-systems do.
The btrfs snapshot-mechanism seems to be what I am looking for, in
combination with a daemon monitoring the free space it should be
possible to create a snapshot every
(This is a review patch to seek comments and review, not yet
ready for the integration).
The motivation to write this patch is that 'btrfs fi show'
shows the stale information after the dev del.
So this adds two ioctls to read fsinfo and devinfo from the
kernel and report to the user.
This is
As of now btrfs fi show reads the disks directly to report
the list of fsids and its disks and the output can be
inconsistent with the kernel dev changes, mainly after the
dev del / add.
This patch adds -k|-K option to the btrfs fi show command
so that it reads from the kernel instead of
This adds two ioctl BTRFS_IOC_GET_FSIDS and BTRFS_IOC_GET_DEVS
which reads the btrfs_fs_devices and btrfs_device structure
from the kernel respectively.
The information in these structure are useful to report the
device/fs information in line with the kernel operations and
thus immediately
On Tue, May 07, 2013 at 10:44:05AM +0200, Stefan Behrens wrote:
On Mon, 6 May 2013 23:11:20 +0200, David Sterba wrote:
Superblock is always 4k, but metadata blocks may be larger. We have to
use the appropriate block size when doing checksums, otherwise they're
wrong.
Signed-off-by:
Quoting David Sterba (2013-05-07 07:54:49)
On Mon, May 06, 2013 at 08:41:06PM -0400, Chris Mason wrote:
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 988b860..4de2351 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1690,15 +1690,19 @@ static int
On Fri, May 10, 2013 Liu Bo wrote:
On Thu, May 09, 2013 at 03:41:49PM -0500, Kyle Gates wrote:
I'll preface that I'm running Ubuntu 13.04 with the standard 3.8
series kernel so please disregard if this has been fixed in higher
versions. This is on a btrfs RAID1 with 3 then 4 disks.
My use case
One the things that is frustrating me the most at this point from a user
perspective regarding btrfs is the current lack of virtual devices to
describe volumes and subvolumes. The current method of simply using a
random member device or a LABEL or a UUID is just not working well for
me.
On 05/10/2013 13:20, David Sterba wrote:
On Tue, May 07, 2013 at 10:44:05AM +0200, Stefan Behrens wrote:
On Mon, 6 May 2013 23:11:20 +0200, David Sterba wrote:
Superblock is always 4k, but metadata blocks may be larger. We have to
use the appropriate block size when doing checksums, otherwise
On Fri, May 10, 2013 at 04:26:32PM +0200, Stefan Behrens wrote:
On 05/10/2013 13:20, David Sterba wrote:
On Tue, May 07, 2013 at 10:44:05AM +0200, Stefan Behrens wrote:
On Mon, 6 May 2013 23:11:20 +0200, David Sterba wrote:
Superblock is always 4k, but metadata blocks may be larger. We have
Quoting David Sterba (2013-05-06 17:11:20)
Superblock is always 4k, but metadata blocks may be larger. We have to
use the appropriate block size when doing checksums, otherwise they're
wrong.
The size coming in from the md should be correct. See this commit from
my integration branch
Hi list,
I am using kernel 3.9.0, btrfs-progs 0.20-rc1-253-g7854c8b.
I have a three disk array of level single:
# btrfs fi sh
Label: none uuid: 2e905f8f-e525-4114-afa6-cce48f77b629
Total devices 3 FS bytes used 3.80TB
devid1 size 2.73TB used 2.25TB path /dev/sdd
On Fri, May 10, 2013 at 10:07:56PM +0200, Marcus Lövgren wrote:
Hi list,
I am using kernel 3.9.0, btrfs-progs 0.20-rc1-253-g7854c8b.
I have a three disk array of level single:
# btrfs fi sh
Label: none uuid: 2e905f8f-e525-4114-afa6-cce48f77b629
Total devices 3 FS bytes used
On May 10, 2013, at 10:21 PM, Hugo Mills h...@carfax.org.uk wrote:
On Fri, May 10, 2013 at 10:07:56PM +0200, Marcus Lövgren wrote:
Hi list,
I am using kernel 3.9.0, btrfs-progs 0.20-rc1-253-g7854c8b.
I have a three disk array of level single:
# btrfs fi sh
Label: none uuid:
Yes, you were right! Adding another drive to the array made it
continue without errors. Is this already reported as a bug?
Thanks for the help,
Marcus
2013/5/10 Remco Hosman - Yerf IT re...@yerf-it.nl:
On May 10, 2013, at 10:21 PM, Hugo Mills h...@carfax.org.uk wrote:
On Fri, May 10, 2013 at
On Fri, May 10, 2013 at 11:43:34PM +0200, Marcus Lövgren wrote:
Yes, you were right! Adding another drive to the array made it continue
without errors. Is this already reported as a bug?
I believe it has been, yes. I think we've even had a patch out for
it. I haven't looked to see if it's
19 matches
Mail list logo
