Re: 0.56.6: MDS asserts on restart
Am 10.05.13 15:21, schrieb Christopher Kunz: Hi all, after our update to 0.56.6, all MDSes assert and crash on start. This is not essential for our setup, but still not great. We assume this might be due to a bug - see the nopaste below for a trace. For reference: I created http://tracker.ceph.com/issues/5037 for this issue. Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
0.56.6: MDS asserts on restart
Hi all, after our update to 0.56.6, all MDSes assert and crash on start. This is not essential for our setup, but still not great. We assume this might be due to a bug - see the nopaste below for a trace. http://nopaste.info/aa06c50a2f.html Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
0.56 scrub OSD memleaks, WAS Re: [0.48.3] OSD memory leak when scrubbing
Am 16.02.13 10:09, schrieb Wido den Hollander: On 02/16/2013 08:09 AM, Andrey Korolyov wrote: Can anyone who hit this bug please confirm that your system contains libc 2.15+? Hello, when we started a deep scrub on our 0.56.2 cluster today, we saw a massive memleak about 1 hour into the scrub. One OSD claimed over 53GByte within 10 minutes. We had to restart the OSD to keep the cluster stable. Another OSD is currently claiming about 27GByte and will be restarted soon. All circumstantial evidence points to the deep scrub as the source of the leak. One affected node is running libc 2.15 (Ubuntu 12.04 LTS), the other one is using libc 2.11.3 (Debian Squeeze). So it seems this is not a libc-dependant issue. We have disabled scrub completely. Regards, --ck PS: Do we have any idea when this will be fixed? -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: the autobuild gpg key expired!
Am 08.02.13 07:46, schrieb Sage Weil: wget -q -O- https://raw.github.com/ceph/ceph/master/keys/autobuild.asc | sudo apt-key add - This doesn't work because raw.github.com uses a certificate issued to CN = *.a.ssl.fastly.net for whatever reason, and wget will complain. It complains rightly, because there is no way to verifiy that this is *actually* github.com we're speaking to. If you want the key regardless, you can use this line: wget --no-check-certificate -q -O- https://raw.github.com/ceph/ceph/master/keys/autobuild.asc | sudo apt-key add - Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Current OSD weight vs. target weight
Hi, if run during a user-issued reweight (i.e. ceph osd crush reweight x y), ceph osd tree shows the target weight of an OSD. Is there a way to see the *current* weight of the OSD? We would like to be able to approximate the amount of rollback necessary per OSD if we need to cancel a larger reweight at some point. This seems impossible, though, without knowing the current weight. Any hints how to do this? Regards, --ck -- filoo GmbH Dr. Christopher Kunz E-Mail: ch...@filoo.de Tel.: (+49) 0 52 41 8 67 30 -18 Fax: (+49) 0 52 41 / 8 67 30 -20 Please sign encrypt mail wherever possible, my key: C882 8ED1 7DD1 9011 C088 EA50 5CFA 2EEB 397A CAC1 Moltkestraße 25a 0 Gütersloh HRB4355, AG Gütersloh Geschäftsführer: S.Grewing, J.Rehpöhler, Dr. C.Kunz Filoo im Web: http://www.filoo.de/ Folgen Sie uns auf Twitter: http://twitter.com/filoogmbh Werden Sie unser Fan auf Facebook: http://facebook.com/filoogmbh -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Are there significant performance enhancements in 0.56.x to be expected soon or planned in the near future?
Hi, Yes, 0.56(.1) has a significant performance increase compared to 0.48 That is not exactly the OP's question, though. If I understand correctly, she is concerned about ongoing performance improvements within the bobtail branch, i.e. between 0.56.1 and 0.56.X (with X1). Jutta, what kind of use case do you have in mind, i.e. how complex are your benchmarking scenarios? Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs vulnerable to hash-DoS attack
Hi all, since a couple people here are using btrfs (we, fortunately, are not), I thought you might be interested in this blog entry: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/ Basically, it seems that if you create files with filenames that have colliding CRC32 hashes, all kind of hell breaks loose. Definitely an interesting read. Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Best practice with 0.48.2 to take a node into maintenance
Hey, That has to be old information - we're using it in anger on 64 bit x86 machines, from both Intel and AMD. I have no idea about ARM etc, however. just to make absolutely sure: Are you using kexec in anger to switch Ceph nodes to new kernels? I'm very doubtful that the approach will work seamlessly with Ceph, as it is rather picky regarding kernel state... Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Best practice with 0.48.2 to take a node into maintenance
Am 03.12.12 20:14, schrieb Josh Durgin: On 12/03/2012 11:05 AM, Oliver Francke wrote: Hi *, well, even if 0.48.2 is really stable and reliable, it is not everytime the case with linux kernel. We have a couple of nodes, where an update would make life better. So, as our OSD-nodes have to care for VM's too, it's not the problem to let them drain so migrate all of them to other nodes. Just reboot? Perhaps not, cause all OSD's will begin to remap/backfill, they are instructed to do so. Well, declare them as osd lost? Dangerous. Is there another way I miss in doing node-maintenance? Will we have to wait for bobtail for far less hassle with all remapping and resources? By default the monitors won't mark an OSD out in the time it takes to reboot, but if maintenance takes longer, you can drain data from the node. Hi, what time is that (in seconds) and how can we reliably test this? Regards, --ck -- To unsubscribe from this list: send the line unsubscribe ceph-devel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
