Re: on disk encryption

As a special use-case I would propose to do the encryption inside the qemu-rbd driver (similar to the qcow2 driver). This would also encrypt the network traffic from the KVM host to the osd. I know that this is probably not the generic aproach for on disk encryption, but it would provide some extr

Re: Ceph and KVM live migration

lations are the same: > > qemu 1.0.17 > > ceph 0.47.3 > > libvirt 0.9.12 > > > > I have googled around and found that if I call migration with --unsafe > > option then it should go. And indeed: it works. Apparently this check > > introduced in libvirt 0.9.12 . Did quick downgrade to lib

Re: Ceph on btrfs 3.4rc

Same thing here. I've tried really hard, but even after 12 hours I wasn't able to get a single warning from btrfs. I think you cracked it! Thanks, Christian 2012/5/24 Martin Mailand : > Hi, > the ceph cluster is running under heavy load for the last 13 hours without a > problem, dmesg is empty

Re: Ceph on btrfs 3.4rc

Same thing here. I've tried really hard, but even after 12 hours I wasn't able to get a single warning from btrfs. I think you cracked it! Thanks, Christian 2012/5/24 Martin Mailand : > Hi, > the ceph cluster is running under heavy load for the last 13 hours without a > problem, dmesg is empty

Re: Ceph on btrfs 3.4rc

2012/5/22 Josef Bacik : >> > > Yeah you would also need to change orphan_meta_reserved.  I fixed this by just > taking the BTRFS_I(inode)->lock when messing with these since we don't want to > take up all that space in the inode just for a marker.  I ran this patch for 3 > hours with no issues, let

Re: Ceph on btrfs 3.4rc

2012/5/22 Josef Bacik : >> > > Yeah you would also need to change orphan_meta_reserved.  I fixed this by just > taking the BTRFS_I(inode)->lock when messing with these since we don't want to > take up all that space in the inode just for a marker.  I ran this patch for 3 > hours with no issues, let

Re: Ceph on btrfs 3.4rc

2012/5/21 Miao Xie : > Hi Josef, > > On fri, 18 May 2012 15:01:05 -0400, Josef Bacik wrote: >> diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h >> index 9b9b15f..492c74f 100644 >> --- a/fs/btrfs/btrfs_inode.h >> +++ b/fs/btrfs/btrfs_inode.h >> @@ -57,9 +57,6 @@ struct btrfs_inode { >>  

Re: Ceph on btrfs 3.4rc

2012/5/21 Miao Xie : > Hi Josef, > > On fri, 18 May 2012 15:01:05 -0400, Josef Bacik wrote: >> diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h >> index 9b9b15f..492c74f 100644 >> --- a/fs/btrfs/btrfs_inode.h >> +++ b/fs/btrfs/btrfs_inode.h >> @@ -57,9 +57,6 @@ struct btrfs_inode { >>  

Re: Designing a cluster guide

2012/5/21 Stefan Priebe - Profihost AG : > Am 20.05.2012 10:31, schrieb Christian Brunner: >>> That's exactly what i thought too but then you need a seperate ceph / rbd >>> cluster for each type. >>> >>> Which will result in a minimum of: >>>

Re: Designing a cluster guide

2012/5/20 Tim O'Donovan : >> - High performance Block Storage (RBD) >> >>   Many large SATA SSDs for the storage (prbably in a RAID5 config) >>   stec zeusram ssd drive for the journal > > How do you think standard SATA disks would perform in comparison to > this, and is a separate journaling devic

Re: Designing a cluster guide

2012/5/20 Stefan Priebe : > Am 20.05.2012 10:19, schrieb Christian Brunner: > >> - Cheap Object Storage (S3): >> >>   Many 3,5'' SATA Drives for the storage (probably in a RAID config) >>   A small and cheap SSD for the journal >> >> - Basic Blo

Re: Designing a cluster guide

2012/5/20 Stefan Priebe : > Am 19.05.2012 18:15, schrieb Alexandre DERUMIER: > >> Hi, >> >> For your journal , if you have money, you can use >> >> stec zeusram ssd drive. (around 2000€ /8GB / 10 iops read/write with >> 4k block). >> I'm using them with zfs san, they rocks for journal. >> http:

Re: is rados block cluster production ready ?

2012/5/18 Alexandre DERUMIER : > Hi Christian, > thanks for your response. > >>>We are using 0.45 in production. Recent ceph versions are quite stable >>>(although we hat some troubles with excessive logging and a full log >>>partition lately which caused our cluster to halt). > > excessive logging

Re: is rados block cluster production ready ?

2012/5/18 Alexandre DERUMIER : > Hi, > I'm going to build a rados block cluster for my kvm hypervisors. > > Is it already production ready ? (stable,no crash) We are using 0.45 in production. Recent ceph versions are quite stable (although we hat some troubles with excessive logging and a full log

Re: Ceph on btrfs 3.4rc

2012/5/17 Josef Bacik : > On Thu, May 17, 2012 at 05:12:55PM +0200, Martin Mailand wrote: >> Hi Josef, >> no there was nothing above. Here the is another dmesg output. >> > > Hrm ok give this a try and hopefully this is it, still couldn't reproduce. > Thanks, > > Josef Well, I hate to say it, but

Re: Ceph on btrfs 3.4rc

2012/5/17 Josef Bacik : > On Thu, May 17, 2012 at 05:12:55PM +0200, Martin Mailand wrote: >> Hi Josef, >> no there was nothing above. Here the is another dmesg output. >> > > Hrm ok give this a try and hopefully this is it, still couldn't reproduce. > Thanks, > > Josef Well, I hate to say it, but

[PATCH 2/2 v2] rbd: skip empty blocks during import

Check for empty blocks while importing an image. When a read block only consists of zeroes, the import is simply skipping the write. This way you non-sparse images will become sparse rbd images. v1 -> v2: fix a signedness warning Signed-off-by: Christian Brunner --- src/rbd.cc |

[PATCH 1/2 v2] rbd: allow importing from stdin

This patch allows importing images from stdin with the following command: rbd import --size= - [dest-image] v1 -> v2: stat stdin as well Signed-off-by: Christian Brunner --- src/rbd.cc | 26 +++--- 1 files changed, 19 insertions(+), 7 deletions(-) diff --git a/

[PATCH 2/2] rbd: skip empty blocks during import

Check for empty blocks while importing an image. When a read block only consists of zeroes, the import is simply skipping the write. This way you non-sparse images will become sparse rbd images. Signed-off-by: Christian Brunner --- src/rbd.cc | 44

[PATCH 1/2] rbd: allow importing from stdin

This patch allows importing images from stdin with the following command: rbd import --size= - [dest-image] Signed-off-by: Christian Brunner --- src/rbd.cc | 37 + 1 files changed, 25 insertions(+), 12 deletions(-) diff --git a/src/rbd.cc b/src/rbd.cc

Re: Ceph on btrfs 3.4rc

2012/5/10 Josef Bacik : > On Fri, Apr 27, 2012 at 01:02:08PM +0200, Christian Brunner wrote: >> Am 24. April 2012 18:26 schrieb Sage Weil : >> > On Tue, 24 Apr 2012, Josef Bacik wrote: >> >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote: >>

Re: Ceph on btrfs 3.4rc

2012/5/10 Josef Bacik : > On Fri, Apr 27, 2012 at 01:02:08PM +0200, Christian Brunner wrote: >> Am 24. April 2012 18:26 schrieb Sage Weil : >> > On Tue, 24 Apr 2012, Josef Bacik wrote: >> >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote: >>

Re: Ceph on btrfs 3.4rc

2012/5/3 Josef Bacik : > On Thu, May 03, 2012 at 09:38:27AM -0700, Josh Durgin wrote: >> On Thu, 3 May 2012 11:20:53 -0400, Josef Bacik >> wrote: >> > On Thu, May 03, 2012 at 08:17:43AM -0700, Josh Durgin wrote: >> > >> > Yeah all that was in the right place, I rebooted and I magically >> > stoppe

Re: Ceph on btrfs 3.4rc

2012/5/3 Josef Bacik : > On Thu, May 03, 2012 at 09:38:27AM -0700, Josh Durgin wrote: >> On Thu, 3 May 2012 11:20:53 -0400, Josef Bacik >> wrote: >> > On Thu, May 03, 2012 at 08:17:43AM -0700, Josh Durgin wrote: >> > >> > Yeah all that was in the right place, I rebooted and I magically >> > stoppe

Re: Ceph on btrfs 3.4rc

2012/4/29 tsuna : > On Fri, Apr 20, 2012 at 8:09 AM, Christian Brunner > wrote: >> After running ceph on XFS for some time, I decided to try btrfs again. >> Performance with the current "for-linux-min" branch and big metadata >> is much better. > > I'

Re: Ceph on btrfs 3.4rc

2012/4/29 tsuna : > On Fri, Apr 20, 2012 at 8:09 AM, Christian Brunner > wrote: >> After running ceph on XFS for some time, I decided to try btrfs again. >> Performance with the current "for-linux-min" branch and big metadata >> is much better. > > I'

Re: Ceph on btrfs 3.4rc

Am 24. April 2012 18:26 schrieb Sage Weil : > On Tue, 24 Apr 2012, Josef Bacik wrote: >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote: >> > After running ceph on XFS for some time, I decided to try btrfs again. >> > Performance with the current &qu

Re: Ceph on btrfs 3.4rc

Am 24. April 2012 18:26 schrieb Sage Weil : > On Tue, 24 Apr 2012, Josef Bacik wrote: >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote: >> > After running ceph on XFS for some time, I decided to try btrfs again. >> > Performance with the current &qu

Re: Ceph on btrfs 3.4rc

Am 24. April 2012 18:26 schrieb Sage Weil : > On Tue, 24 Apr 2012, Josef Bacik wrote: >> On Fri, Apr 20, 2012 at 05:09:34PM +0200, Christian Brunner wrote: >> > After running ceph on XFS for some time, I decided to try btrfs again. >> > Performance with the current &qu

Re: Ceph on btrfs 3.4rc

.00MB, used=0.00 A few more btrfs_orphan_commit_root WARNINGS are present too. If needed I could upload the messages file. Regards, Christian Am 20. April 2012 17:09 schrieb Christian Brunner : > After running ceph on XFS for some time, I decided to try btrfs again. > Performance with the c

Re: Ceph on btrfs 3.4rc

.00MB, used=0.00 A few more btrfs_orphan_commit_root WARNINGS are present too. If needed I could upload the messages file. Regards, Christian Am 20. April 2012 17:09 schrieb Christian Brunner : > After running ceph on XFS for some time, I decided to try btrfs again. > Performance with the c

Ceph on btrfs 3.4rc

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I'm still seeing is a warning that seems to occur from time to time: [87703.784552] [ cut here ]

Ceph on btrfs 3.4rc

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I'm still seeing is a warning that seems to occur from time to time: [87703.784552] [ cut here ]

Inconsistent rbd header

This is probably going in the same direction as the report by Oliver Francke. Ceph is reporting an inconsistent PG. Running a scrub on the PG gave me the folling messages: 2012-03-16 12:55:17.287415 log 2012-03-16 12:55:12.179529 osd.14 10.255.0.63:6818/2014 34280 : [ERR] 2.117 osd.0: soid 818b

Re: [rsyslog] next question: templates, JSON and MongoDB

16, 2012 9:43 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] next question: templates, JSON and MongoDB >> >> >> >> > -Original Message- >> > From: rsyslog-boun...@lists.adiscon.com [mailto:rsyslog- >> > boun...@lists.adiscon.com] On B

Re: [rsyslog] next question: templates, JSON and MongoDB

Hi Rainer, did you take a look at my JSON strgen module? http://lists.adiscon.net/pipermail/rsyslog/2011-June/013383.html I think adding key:value pairs is much easier than manually crafting the template string. The only disadvantage I'm seeing is, that it isn't possible to specify a hierarchy

protocol version mismatch

Hi, I've just updated our ceph-cluster from 0.39 to 0.42.2. Now I'm seeing a lot of messages like these in the OSD log: Mar 2 10:15:43 os00 osd.003[15096]: 7f0b9831c700 -- 10.255.0.60:6821/15095 >> 10.255.0.61:6812/22474 pipe(0x2e74100 sd=47 pgs=0 cs=0 l=0).connect protocol version mismatch, my

Re: Strange prformance degradation when COW writes happen at fixed offsets

2012/2/24 Nik Markovic : > To add... I also tried nodatasum (only) and nodatacow otions. I found > somewhere that nodatacow doesn't really mean tthat COW is disabled. > Test data is still the same - CPU spikes and times are the same. > > On Fri, Feb 24, 2012 at 2:38 PM, Nik Markovic > wrote: >> O

Re: about attaching rbd volume from instance on KVM

Libvirt is trying to set security lables even for network shares. This will not work. I think this is fixed in newer libvirt versions. For older versions you can try this patch: http://www.redhat.com/archives/libvir-list/2011-May/msg01446.html Regards, Christian 2012/2/4 Masuko Tomoya : > Hi, al

ceph on XFS

Hi, reading the list archives, I get the impression that XFS is the second best alternative to btrfs. But when I start an ceph-osd on an XFS volume, there is still a big warning: WARNING: not btrfs or ext3. We don't currently support file systems other than btrfs and ext3 (data=jour

Re: Btrfs slowdown with ceph (how to reproduce)

2012/1/23 Chris Mason : > On Mon, Jan 23, 2012 at 01:19:29PM -0500, Josef Bacik wrote: >> On Fri, Jan 20, 2012 at 01:13:37PM +0100, Christian Brunner wrote: >> > As you might know, I have been seeing btrfs slowdowns in our ceph >> > cluster for quite some time. Even wit

Re: Btrfs slowdown with ceph (how to reproduce)

2012/1/23 Chris Mason : > On Mon, Jan 23, 2012 at 01:19:29PM -0500, Josef Bacik wrote: >> On Fri, Jan 20, 2012 at 01:13:37PM +0100, Christian Brunner wrote: >> > As you might know, I have been seeing btrfs slowdowns in our ceph >> > cluster for quite some time. Even wit

Btrfs slowdown with ceph (how to reproduce)

As you might know, I have been seeing btrfs slowdowns in our ceph cluster for quite some time. Even with the latest btrfs code for 3.3 I'm still seeing these problems. To make things reproducible, I've now written a small test, that imitates ceph's behavior: On a freshly created btrfs filesystem (

Btrfs slowdown with ceph (how to reproduce)

As you might know, I have been seeing btrfs slowdowns in our ceph cluster for quite some time. Even with the latest btrfs code for 3.3 I'm still seeing these problems. To make things reproducible, I've now written a small test, that imitates ceph's behavior: On a freshly created btrfs filesystem (

Re: [3.2-rc7] slowdown, warning + oops creating lots of files

2012/1/7 Christian Brunner : > 2012/1/5 Chris Mason : >> On Fri, Jan 06, 2012 at 07:12:16AM +1100, Dave Chinner wrote: >>> On Thu, Jan 05, 2012 at 02:45:00PM -0500, Chris Mason wrote: >>> > On Thu, Jan 05, 2012 at 01:46:57PM -0500, Chris Mason wrote: >>> &g

Re: [3.2-rc7] slowdown, warning + oops creating lots of files

2012/1/5 Chris Mason : > On Fri, Jan 06, 2012 at 07:12:16AM +1100, Dave Chinner wrote: >> On Thu, Jan 05, 2012 at 02:45:00PM -0500, Chris Mason wrote: >> > On Thu, Jan 05, 2012 at 01:46:57PM -0500, Chris Mason wrote: >> > > On Thu, Jan 05, 2012 at 10:01:22AM +1100, Dave Chinner wrote: >> > > > On T

Re: BTRFS Warning

2011/12/21 Jens Rehpöhler : > Am 19.12.2011 19:51, schrieb Gregory Farnum: >> On Mon, Dec 19, 2011 at 12:28 AM, Jens Rehpöhler >> wrote: >>> Good morning !! >>> >>> i got the following warning as soon as i use btrfs as underlaying >>> filesystem (for stability reasons i use ext4). I converted one

Re: Understanding Ceph

Hi Bill, 2011/12/18 Bill Hastings : > I am trying to get my feet wet with Ceph and RADOS. My aim is to use > it as a block device for KVM instances. My understanding is that > virtual disks get striped at 1 MB boundaries by default. Does that > mean that there are going to be 1MB files on disks?

Re: WARNING: at fs/btrfs/extent-tree.c:5980

Sorry - I forgot to mention, that I'm still seeing this with: [PATCH] Btrfs: update global block_rsv when creating a new block group Christian 2011/12/13 Christian Brunner : > Hi, > > with the latest btrfs for-linus I'm seeing seeing occasional > btrfs_alloc_free_block war

WARNING: at fs/btrfs/extent-tree.c:5980

Hi, with the latest btrfs for-linus I'm seeing seeing occasional btrfs_alloc_free_block warnings on several nodes in our ceph cluster. Before the warning there is an additional block rsv -28 message, but there is plenty of free space on the disk. [201653.774412] btrfs: block rsv returned -28 [2

Re: avoid redundant block group free-space checks

2011/12/12 Alexandre Oliva : > It was pointed out to me that the test for enough free space in a block > group was wrong in that it would skip a block group that had most of its > free space reserved by a cluster. > > I offer two mutually exclusive, (so far) very lightly tested patches to > address

Re: [PATCH 02/20] Btrfs: initialize new bitmaps' list

2011/12/12 Alexandre Oliva : > On Dec  7, 2011, Christian Brunner wrote: > >> With this patch applied I get much higher write-io values than without >> it. Some of the other patches help to reduce the effect, but it's >> still significant. > >> io

Re: [PATCH 02/20] Btrfs: initialize new bitmaps' list

2011/12/7 Christian Brunner : > 2011/12/1 Christian Brunner : >> 2011/12/1 Alexandre Oliva : >>> On Nov 29, 2011, Christian Brunner wrote: >>> >>>> When I'm doing havy reading in our ceph cluster. The load and wait-io >>>> on

Re: ceph and ext4

2011/11/15 Andreas Dilger : > Coincidentally, we have someone working in those patches again. The main > obstacle for accepting the previous patch as-is was that Ted wanted to add > support for "medium-sized" xattrs that are addressed as a string of blocks, > instead of via an inode. > > This wi

Re: libvirtd + rbd - stale kvm after migrate

Hi Florian, live migration with rbd images usually works fine. A few recommendations: - You should not map the image on the host, while using it in a VM with the qemu driver. - For testing I would remove the ISO-Image from your VM. (Not sure if that matters). Also I'm not using cephx authenticat

Re: [PATCH 02/20] Btrfs: initialize new bitmaps' list

2011/12/1 Christian Brunner : > 2011/12/1 Alexandre Oliva : >> On Nov 29, 2011, Christian Brunner wrote: >> >>> When I'm doing havy reading in our ceph cluster. The load and wait-io >>> on the patched servers is higher than on the unpatched ones. >> &g

Re: 'ceph -w' in 0.39

2011/12/5 Sage Weil : > Hi Christian, > > On Mon, 5 Dec 2011, Christian Brunner wrote: >> I've just updated to 0.39. Everything seems to be fine, except one >> minor thing I noticed: >> >> 'ceph -w' output stops after a few minutes. With "debug

'ceph -w' in 0.39

I've just updated to 0.39. Everything seems to be fine, except one minor thing I noticed: 'ceph -w' output stops after a few minutes. With "debug ms = 1" it ends with these lines: 2011-12-05 14:45:52.939300 7fc700637700 -- 10.255.0.21:0/14145 <== mon.2 10.255.0.22:6789/0 315 mon_observe_noti

Re: [PATCH] Btrfs: protect orphan block rsv with spin_lock

2011/12/2 Josef Bacik : > We've been seeing warnings coming out of the orphan commit stuff forever from > ceph.  Turns out it's because we're racing with checking if the orphan block > reserve is set, because we clear it outside of the spin_lock.  So leave the > normal fastpath checks where they ar

Re: [PATCH 02/20] Btrfs: initialize new bitmaps' list

2011/12/1 Alexandre Oliva : > On Nov 29, 2011, Christian Brunner wrote: > >> When I'm doing havy reading in our ceph cluster. The load and wait-io >> on the patched servers is higher than on the unpatched ones. > > That's unexpected. > >> This seems

Re: [PATCH 02/20] Btrfs: initialize new bitmaps' list

2011/11/28 Alexandre Oliva : > We're failing to create clusters with bitmaps because > setup_cluster_no_bitmap checks that the list is empty before inserting > the bitmap entry in the list for setup_cluster_bitmap, but the list > field is only initialized when it is restored from the on-disk free >

Re: WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0

2011/11/26 Stefan Kleijkers : > Hello Josef, > > I've new results, is this the trace you are looking for? > > Trace of OSD0: http://pastebin.com/gddLBXE4 > Dmesg of OSD0: http://pastebin.com/Uebzgkjv > > OSD1 crashed a while later with the same messages. > > Stefan Hi Josef, I ran your patch on o

Re: pginfo updates

2011/11/24 Christian Brunner : > Sorry, just one more question: > > Why is pginfo truncated every time a write is performed to the PG? > Forget about my question. Sorry for the noise, Christian -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in th

Re: pginfo updates

Sorry, just one more question: Why is pginfo truncated every time a write is performed to the PG? Thanks, Christian 2011/11/24 Christian Brunner : > Hmmm, OK. - This really seems to belong to one virtual machine, that > is writing to a single object over and over again. > > Thanks f

Re: pginfo updates

urprised > that one PG has so much more activity than the others, but that's why > that inode has so much activity. > > What are you doing with this installation, and roughly how many PGs > are on the node? > > On Thu, Nov 24, 2011 at 3:33 AM, Christian Brunner wrote: >

pginfo updates

I'm running a btrfs-debug patch on one of our nodes. This patch prints calls to btrfs_orphan_add. I'm still waiting for the problem the patch was intended to trace, but in the logs I found something ceph related I don't understand: When I look at the btrfs_orphan_add messages there is one inode th

Recommended btrfs mount options

Reading the latest pull request by Chris Mason, I was wondering about the recommended mount options for an OSD-Filesystem. In the past I came across the following btrfs options, that were used in conjunction with ceph: - nodatacow: To avoid fragmentation. I think this one makes sense when you are

Re: BUG at fs/btrfs/inode.c:1587

2011/11/16 Chris Mason : > On Tue, Nov 15, 2011 at 09:19:53AM +0100, Christian Brunner wrote: >> Hi, >> >> this time I've hit a new bug. This happened while ceph was rebuilding >> his filestore (heavy io). >> >> The btrfs version is from 3.2-rc1, appl

Re: ceph and ext4

2011/11/14 Martin Mailand : > Hi Christian, > I am not sure if you noticed, but your ext4 bug is fixed in mainline. I am > running a ceph cluster with 40+ vms for over a week by now, without any > problems. An fsck.ext4 shows the ext4 is clean. > The performance of ext4 is much better than btrfs, n

BUG at fs/btrfs/inode.c:1587

Hi, this time I've hit a new bug. This happened while ceph was rebuilding his filestore (heavy io). The btrfs version is from 3.2-rc1, applied to a 3.0 kernel. Regards, Christian [28981.550478] [ cut here ] [28981.555625] kernel BUG at fs/btrfs/inode.c:1587! [28981.56077

Re: btrfs-work master repo

tpath+0x16/0x1b [12649.130482] ---[ end trace 6f256945fc353904 ]--- To aid debuging, I can also send you an ftrace with btrfs events and function_graph enabled. Just tell me if you need it. Thanks, Christian 2011/11/13 Christian Brunner : > Hi Josef, > > I've patched one of our ceph n

btrfs-work master repo

Hi Josef, I've patched one of our ceph nodes with the stuff in your master repo (including lxo's patches). The WARNING in inode.c seems to be gone now, but load is still going up after a day. Another thing I've witnessed is that I'm getting a new warning, when I umount the filesystem (see below)

Re: OSD hit suicide timeout

2011/11/11 Sage Weil : > Hi Christian, > > Do you have a core file?  Can you dump the thread stack traces so we can > see if it got hung up on a syscall or somewhere internally (thread apply > all bt)? I'm not sure if it's from btrfs, but ther is no kernel warning at that time. I'm missing some d

OSD hit suicide timeout

I have upgraded to 0.38 today. After a few hours two of my OSDs crashed with "hit suicide timeout". After a restart, they are up again. I've seen this in prior versions, so I don't think it's related to the upgrade. I just wanted to report that it's still there. Here is what I've found in our sys

Re: WARNING: at fs/btrfs/inode.c:2198 btrfs_orphan_commit_root+0xa8/0xc0

2011/11/9 Stefan Kleijkers : > Hello, > > I'm seeing a lot of warnings in dmesg with a BTRFS filesystem. I'm using the > 3.1 kernel, I found a patch for these warnings ( > http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) > , but that patc

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/31 Christian Brunner : > 2011/10/31 Christian Brunner : >> 2011/10/31 Christian Brunner : >>> >>> The patch didn't hurt, but I've to tell you that I'm still seeing the >>> same old problems. Load is going up again: >>> >>>

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/31 Christian Brunner : > 2011/10/31 Christian Brunner : >> >> The patch didn't hurt, but I've to tell you that I'm still seeing the >> same old problems. Load is going up again: >> >>  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIM

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/27 Josef Bacik : > On Tue, Oct 25, 2011 at 01:56:48PM +0200, Christian Brunner wrote: >> 2011/10/24 Josef Bacik : >> > On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote: >> >> [adding linux-btrfs to cc] >> >> >> >> Josef, Chris,

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/27 Josef Bacik : > On Tue, Oct 25, 2011 at 01:56:48PM +0200, Christian Brunner wrote: >> 2011/10/24 Josef Bacik : >> > On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote: >> >> [adding linux-btrfs to cc] >> >> >> >> Josef, Chris,

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/26 Christian Brunner : > 2011/10/25 Josef Bacik : >> On Tue, Oct 25, 2011 at 04:15:45PM -0400, Chris Mason wrote: >>> On Tue, Oct 25, 2011 at 11:05:12AM -0400, Josef Bacik wrote: >>> > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote: >

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/26 Christian Brunner : > 2011/10/25 Josef Bacik : >> On Tue, Oct 25, 2011 at 04:15:45PM -0400, Chris Mason wrote: >>> On Tue, Oct 25, 2011 at 11:05:12AM -0400, Josef Bacik wrote: >>> > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote: >

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/26 Sage Weil : > On Wed, 26 Oct 2011, Christian Brunner wrote: >> >> > Christian, have you tweaked those settings in your ceph.conf?  It would >> >> > be >> >> > something like 'journal dio = false'.  If not, can you verify that &

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/26 Sage Weil : > On Wed, 26 Oct 2011, Christian Brunner wrote: >> >> > Christian, have you tweaked those settings in your ceph.conf?  It would >> >> > be >> >> > something like 'journal dio = false'.  If not, can you verify that &

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Josef Bacik : > On Tue, Oct 25, 2011 at 04:15:45PM -0400, Chris Mason wrote: >> On Tue, Oct 25, 2011 at 11:05:12AM -0400, Josef Bacik wrote: >> > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote: >> > > >> > > Attached is a per

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Josef Bacik : > On Tue, Oct 25, 2011 at 04:15:45PM -0400, Chris Mason wrote: >> On Tue, Oct 25, 2011 at 11:05:12AM -0400, Josef Bacik wrote: >> > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote: >> > > >> > > Attached is a per

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Sage Weil : > On Tue, 25 Oct 2011, Josef Bacik wrote: >> At this point it seems like the biggest problem with latency in ceph-osd >> is not related to btrfs, the latency seems to all be from the fact that >> ceph-osd is fsyncing a block dev for whatever reason. > > There is one place whe

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Sage Weil : > On Tue, 25 Oct 2011, Josef Bacik wrote: >> At this point it seems like the biggest problem with latency in ceph-osd >> is not related to btrfs, the latency seems to all be from the fact that >> ceph-osd is fsyncing a block dev for whatever reason. > > There is one place whe

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Josef Bacik : > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote: >> 2011/10/25 Josef Bacik : >> > On Tue, Oct 25, 2011 at 01:56:48PM +0200, Christian Brunner wrote: [...] >> >> >> >> In our Ceph-OSD server we have 4 disks wit

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Josef Bacik : > On Tue, Oct 25, 2011 at 04:25:02PM +0200, Christian Brunner wrote: >> 2011/10/25 Josef Bacik : >> > On Tue, Oct 25, 2011 at 01:56:48PM +0200, Christian Brunner wrote: [...] >> >> >> >> In our Ceph-OSD server we have 4 disks wit

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Josef Bacik : > On Tue, Oct 25, 2011 at 01:56:48PM +0200, Christian Brunner wrote: >> 2011/10/24 Josef Bacik : >> > On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote: >> >> [adding linux-btrfs to cc] >> >> >> >> Josef, Chris,

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/25 Josef Bacik : > On Tue, Oct 25, 2011 at 01:56:48PM +0200, Christian Brunner wrote: >> 2011/10/24 Josef Bacik : >> > On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote: >> >> [adding linux-btrfs to cc] >> >> >> >> Josef, Chris,

PG stuck in scrubbing

Here is another problem I've seen. Unfortunatly I do not have any debug output and it's not reproduceable. While removing an image with "rbd rm" I noticed that rbd stopped making progress. When I looked with "ceph -w" I saw a PG, that was in state "active+clean+scrubbing": 2011-10-25 14:01:34.198

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/24 Chris Mason : > On Mon, Oct 24, 2011 at 03:51:47PM -0400, Josef Bacik wrote: >> On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote: >> > [adding linux-btrfs to cc] >> > >> > Josef, Chris, any ideas on the below issues? >> > >

Re: ceph on btrfs [was Re: ceph on non-btrfs file systems]

2011/10/24 Chris Mason : > On Mon, Oct 24, 2011 at 03:51:47PM -0400, Josef Bacik wrote: >> On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote: >> > [adding linux-btrfs to cc] >> > >> > Josef, Chris, any ideas on the below issues? >> > >

Re: ceph on non-btrfs file systems

Thanks for explaining this. I don't have any objections against btrfs as a osd filesystem. Even the fact that there is no btrfs-fsck doesn't scare me, since I can use the ceph replication to recover a lost btrfs-filesystem. The only problem I have is, that btrfs is not stable on our side and I wond

rbd snap rm error

When I want to delete a snapshot, everything is working, but there is a strange error message: # rbd create --size=100 image # rbd snap create --snap=image-snap1 image # rbd snap ls image 8 image-snap1 104857600 # rbd snap rm --snap=image-snap1 image 2011-10-21 11:35:58.506393 7f4975f66

Re: WARNING: at fs/btrfs/inode.c:2114

2011/10/20 Liu Bo : > On 10/17/2011 11:23 PM, Christian Brunner wrote: >> 2011/10/11 Christian Brunner : >> >> I have updated to a 3.0.6 kernel, with all the btrfs patches from >> josef's git repo this weekend. But I'm still seeing the following >> warn

Re: OSD blocked for more than 120 seconds

>> On Mon, 17 Oct 2011, Martin Mailand wrote: >>> >>> Am 17.10.2011 11:40, schrieb Christian Brunner: >>>> >>>> Our bugreport with RedHat didn't make any progress for a long time, >>>> but last week RedHat made two sugestions:

Re: WARNING: at fs/btrfs/inode.c:2114

2011/10/11 Christian Brunner : > 2011/10/11 Liu Bo : >> On 10/10/2011 12:41 AM, Christian Brunner wrote: >>> I just realized that this is still the same warning I reported some month >>> ago. >>> >>> I thought that this had been fixed with >

Re: OSD blocked for more than 120 seconds

2011/10/15 Martin Mailand : > Hi Christian, > I have a very similar experience, I also used josef's tree and btrfs snaps = > 0, the next problem I had than was excessive fragmentation, so I  used this > patch http://marc.info/?l=linux-btrfs&m=131495014823121&w=2, and changed the > btrfs option to (

  1   2   3   4   >