On 17/07/2013 14:36, Da Chun wrote:
On Ubuntu 13.04, ceph 0.61.4.
I was running an fio read test as below, then it hung:
root@ceph-node2:/mnt# fio -filename=/dev/rbd1 -direct=1 -iodepth 1
-thread -rw=read -ioengine=psync -bs=4k -size=50G -numjobs=16
-group_reporting -name=mytest
mytest: (g=0)
I am using RHEL6.
>From the ceph admin machine I executed:
ceph-deploy install cephserverX
ceph-deploy new cephserverX
ceph-deploy mon create cephserverX
is there a debug mode more verbose than -v that I can enable, in order to see
more what the command ceph-deploy mon create is doing?
Thanks
I'm looking at some SSDs drives to be used as journal.
Seagate 600 should be the better in write intensive operation (like a journal):
http://www.storagereview.com/seagate_600_pro_enterprise_ssd_review
what do you suggest? Is this good enough ?
Should I look for write-intensive operations when se
Hello,
After a reboot one of our monitors is unable to start. We did an
upgrade from 0.61.4 to 0.61.5 last week without problems (the monitor
restarted just fine).
We are getting the following error (I think it is the same as:
http://tracker.ceph.com/issues/5704). I might have missed it on t
Does anyone know how to do this or if this is not possible? We try to modify
the security scope for an existing cephx user but could not figure out how to
add access to a new pool without recreating the user, e.g.,
ceph auth get-or-create client.svl-ceph-openstack-images mon 'allow r' osd
'allow
On 07/22/2013 06:22 AM, Gandalf Corvotempesta wrote:
I'm looking at some SSDs drives to be used as journal.
Seagate 600 should be the better in write intensive operation (like a journal):
http://www.storagereview.com/seagate_600_pro_enterprise_ssd_review
what do you suggest? Is this good enough
2013/7/22 Mark Nelson :
>> http://www.storagereview.com/seagate_600_pro_enterprise_ssd_review
"If you used this SSD for 100% sequential writes, you could
theoretically kill it in a little more than a month."
very bad.
Any other suggestions for SSD device?
_
On 07/22/2013 08:16 AM, Gandalf Corvotempesta wrote:
2013/7/22 Mark Nelson :
http://www.storagereview.com/seagate_600_pro_enterprise_ssd_review
"If you used this SSD for 100% sequential writes, you could
theoretically kill it in a little more than a month."
very bad.
Any other suggestions for
Hi,
My 0.02 :
> Secondly, I'm unclear about how OSDs use the journal. It appears they
write to the journal (in all cases, can't be turned
>off), ack to the client and then read the journal later to write to backing
>storage. Is that correct?
I would like to say NO, the journal w
2013/7/22 Chen, Xiaoxi :
> With “journal writeahead”,the data first write to journal ,ack to the
> client, and write to OSD, note that, the data always keep in memory before
> it write to both OSD and journal,so the write is directly from memory to
> OSDs. This mode suite for XFS and EXT4.
What ha
On 07/22/2013 12:33 PM, pe...@2force.nl wrote:
Hello,
After a reboot one of our monitors is unable to start. We did an upgrade
from 0.61.4 to 0.61.5 last week without problems (the monitor restarted
just fine).
We are getting the following error (I think it is the same as:
http://tracker.ceph.c
On Mon, Jul 22, 2013 at 5:42 AM, w sun wrote:
> Does anyone know how to do this or if this is not possible? We try to modify
> the security scope for an existing cephx user but could not figure out how
> to add access to a new pool without recreating the user, e.g.,
>
> ceph auth get-or-create cli
2013/7/22 Chen, Xiaoxi :
> Imaging you have several writes have been flushed to journal and acked，but
> not yet write to disk. Now the system crash by kernal panic or power
> failure，you will lose your data in ram disk，thus lose data that assumed to be
> successful written.
The same apply in ca
发自我的 iPhone
在 2013-7-23，0:21，"Gandalf Corvotempesta" 写道：
> 2013/7/22 Chen, Xiaoxi :
>> Imaging you have several writes have been flushed to journal and acked，but
>> not yet write to disk. Now the system crash by kernal panic or power
>> failure，you will lose your data in ram disk，thus lose d
On 07/22/2013 04:59 PM, pe...@2force.nl wrote:
Hi Joao,
I have sent you the link to the monitor files. I stopped one other
monitor to have a consistent tarball but now it won't start, crashing
with the same error message. I hope there is a trick to get it working
again because now I only have on
Hi,
RAM is *MUCH* more reliable than SSD. I've never seen a single RAM
module (server grade) failed from the latest 5-6 year.
We have had that happen a few times - running primarily IBM hardware.
Then you get those nasty MCEs - so I wouldn't run journals in RAM.
Unless ofcourse you're only u
Hi Joao,
I have sent you the link to the monitor files. I stopped one other
monitor to have a consistent tarball but now it won't start, crashing
with the same error message. I hope there is a trick to get it working
again because now I only have one monitor working and I don't want to
end up
Basically i think endurance is most important for a ceph journal，since the
workload for journal is full write，you can easily caculate how long your ssd
will burn out.. even we assume your ssd only run at 100MB/s in average，you will
burn out 8TB/day and 240TB/month
DCS 3500 is definitely not use
On 07/22/2013 05:53 PM, Chen, Xiaoxi wrote:
> Basically i think endurance is most important for a ceph journal，since the
> workload for journal is full write，you can easily caculate how long your ssd
> will burn out.. even we assume your ssd only run at 100MB/s in average，you
> will burn out 8TB
发自我的 iPhone
在 2013-7-22，23:16，"Gandalf Corvotempesta" 写道：
> 2013/7/22 Chen, Xiaoxi :
>> With “journal writeahead”,the data first write to journal ,ack to the
>> client, and write to OSD, note that, the data always keep in memory before
>> it write to both OSD and journal,so the write is direct
On 07/22/2013 11:26 AM, Chen, Xiaoxi wrote:
>
>
> 发自我的 iPhone
>
> 在 2013-7-23，0:21，"Gandalf Corvotempesta" 写道：
>
>> 2013/7/22 Chen, Xiaoxi :
>>> Imaging you have several writes have been flushed to journal and acked，but
>>> not yet write to disk. Now the system crash by kernal panic or power
2013/7/22 Mark Nelson :
> I don't have any in my test lab, but the DC S3700 continues to look like a
> good option and has a great reputation, but might be a bit pricey. From that
> article it looks like the Micron P400m might be worth looking at too, but
> seems to be a bit slower.
DC S3500 shoul
On 07/22/2013 09:30 AM, Gandalf Corvotempesta wrote:
2013/7/22 Mark Nelson :
I don't have any in my test lab, but the DC S3700 continues to look like a
good option and has a great reputation, but might be a bit pricey. From that
article it looks like the Micron P400m might be worth looking at to
Good evening,
> I have not yet had the opportunity to try one, but something like the
> Marvell Dragonfly might be a very interesting option for servers with
> 24+ drives:
>
> https://origin-www.marvell.com/storage/dragonfly/nvram/
yes, Marvell Dragonfly also looks very promising to me, i like
On Fri, Jul 19, 2013 at 11:04 PM, Noah Watkins wrote:
> On Fri, Jul 19, 2013 at 8:09 AM, ker can wrote:
>>
>> With ceph is there any way to influence the data block placement for a
>> single file ?
>
> AFAIK, no... But, this is an interesting twist. New files written out
> to HDFS, IIRC, will by
On 07/22/2013 01:02 PM, Oliver Fuckner wrote:
> Good evening,
>
>
>> I have not yet had the opportunity to try one, but something like the
>> Marvell Dragonfly might be a very interesting option for servers with
>> 24+ drives:
>>
>> https://origin-www.marvell.com/storage/dragonfly/nvram/
>
> yes
I have a 12 OSD/3 host set up, and have be stuck with a bunch of stuck
pages.
I've verified the OSDs are all up and in. The crushmap looks fine.
I've tried restarting all the daemons.
root@never:/var/lib/ceph/mon# ceph status
health HEALTH_WARN 139 pgs degraded; 461 pgs stuck unclean; r
On Mon, 22 Jul 2013, Gaylord Holder wrote:
>
> I have a 12 OSD/3 host set up, and have be stuck with a bunch of stuck pages.
>
> I've verified the OSDs are all up and in. The crushmap looks fine.
> I've tried restarting all the daemons.
>
>
>
> root@never:/var/lib/ceph/mon# ceph status
>h
Ah, that works now with 0.61. I believe we have tried that with 0.56 before and
it didn't work. Maybe we have missed something. Anyway, don't have a 0.56
system any more to validate.
Thanks much.
--weiguo
> Date: Mon, 22 Jul 2013 09:23:26 -0700
> From: g...@inktank.com
> To: ws...@hotmail.com
On Mon, Jul 22, 2013 at 7:10 PM, Mark Nelson wrote:
> On 07/22/2013 01:02 PM, Oliver Fuckner wrote:
>> Good evening,
>>
>>
>>
>> On the second look you see that they use 4 Sandisk X100 SSDs in RAID5
>> and those SSDs only have 80TBytes Write Endurance each... that makes me
>> nervous.
>
> I'm less
Hi,
On Mon, Jul 22, 2013 at 2:08 AM, Chen, Xiaoxi wrote:
> Hi,
>
> ** **
>
> > Can you share any information on the SSD you are using, is it
> PCIe connected?
>
>Depends, if you use HDD as your OSD data disk, a SATA/SAS SSD is
> enough for you. Instead of Intel 520, I woul
Sage,
The crush tunables did the trick.
why? Could you explain what was causing the problem?
I've haven't installed 3.9 on my RBD servers yet. Will setting crush
tunables back to default or legacy cause me similar problems in the future?
Thank you again Sage!
-Gaylord
On 07/22/2013 02:27
On Mon, 22 Jul 2013, Gaylord Holder wrote:
> Sage,
>
> The crush tunables did the trick.
>
> why? Could you explain what was causing the problem?
This has a good explanation, I think:
http://ceph.com/docs/master/rados/operations/crush-map/#tunables
> I've haven't installed 3.9 on my R
On 07/23/13 07:35, Charles 'Boyo wrote:
Considering using a mSATA to PCIe adapter with a SATA III mSATA SSD.
Any thoughts on what to expect from this combination?
Going PCIe I think I would use a SSD card rather than adding yet another
(relatively slow) bus. I haven't looked at the models but
I would get the cluster up and running and do some experiments before I
spent any time on optimization, much less all this.
On 07/20/2013 09:35 AM, Ta Ba Tuan wrote:
Please help me!
On 07/20/2013 02:11 AM, Ta Ba Tuan wrote:
Hi everyone,
I have *3 nodes (running MON and MDS)*
and *6 data nod
If I understand what the #tunables page is saying, changing the tunables
kicks the OSD re-balancing mechanism a bit and resets it to try again.
I'll see about getting 3.9 kernel in for my RBD maachines, and reset
everything to optimal.
Thanks again.
-Gaylord
On 07/22/2013 04:51 PM, Sage Wei
On Mon, 22 Jul 2013, Gaylord Holder wrote:
> If I understand what the #tunables page is saying, changing the tunables kicks
> the OSD re-balancing mechanism a bit and resets it to try again.
>
> I'll see about getting 3.9 kernel in for my RBD maachines, and reset
> everything to optimal.
Keep in
发自我的 iPhone
在 2013-7-23，4:35，"Charles 'Boyo"
mailto:charlesb...@gmail.com>> 写道：
Hi,
On Mon, Jul 22, 2013 at 2:08 AM, Chen, Xiaoxi
mailto:xiaoxi.c...@intel.com>> wrote:
Hi,
> Can you share any information on the SSD you are using, is it PCIe
connected?
Depends, if you use H
Hi,
I have a three node ceph cluster. ceph -w says health ok . I have
openstack in the same cluster and trying to map cinder and glance onto rbd.
I have followed steps as given in
http://ceph.com/docs/next/rbd/rbd-openstack/
New Settings that is added in cinder.conf for three files
volu
Your email client cannot read this email.
To view it online, please go here:
http://mailczar247.info/display.php?M=203964&C=6bdb1772177fe8d9135ad2e2dc2b0fe2&S=13&L=8&N=2
To stop receiving these
emails:http://mailczar247.info/unsubscribe.php?M=203964&C=6bdb1772177fe8d9135ad2e2dc2b0fe2&L=8&N=13
__
On Sun, Jul 21, 2013 at 12:48 AM, Dominik Mostowiec
wrote:
> Hi,
> Rgw bucket index is in one file (one osd performance issues).
> Is there on roudmap sharding or other change to increase performance?
>
>
Excellent question. Note that the upcoming Dupling release will have
the ability to separate
41 matches
Mail list logo
