Hi,
As far as I know Ceph won't attempt to do any weight modifications. If
you use the default CRUSH map, every devices get a default weight of
1. However this value can be modified while the cluster runs. Simply
update the CRUSH map like so:
# ceph osd crush reweight {name} {weight}
If you need
Pls can someone help me with the ceph.conf for 0.56.2. I have two servers for
STORAGE with 3tb hard drives each and two SSD's each. I want to use OSD data
on the hard drive and osd journal on SSD.
I want to know how osd journal configuration is set to SSD. My SSD is mounted
on /dev/sdb.
I h
I upgraded to ceph 0.56-3 but the problem persist...
OSD starts but after a second it finishes:
2013-02-14 12:18:34.504391 7fae613ea760 10 journal _open journal is
not a block device, NOT checking disk write cache on
'/var/lib/ceph/osd/ceph-0/jour
nal'
2013-02-14 12:18:34.504400 7fae613ea760 1 j
On 02/14/2013 11:24 AM, charles L wrote:
Pls can someone help me with the ceph.conf for 0.56.2. I have two servers for
STORAGE with 3tb hard drives each and two SSD's each. I want to use OSD data
on the hard drive and osd journal on SSD.
I want to know how osd journal configuration is set to
Including ceph-users, as it feels like this belongs there :-)
On 02/14/2013 01:47 PM, Wido den Hollander wrote:
On 02/14/2013 11:24 AM, charles L wrote:
Pls can someone help me with the ceph.conf for 0.56.2. I have two
servers for STORAGE with 3tb hard drives each and two SSD's each. I
want
+1 for Wido
Moreover, if you want to store the journal on a block device, you
should partition your journal disk and assign one partition per OSD
like /dev/sdb1, 2 , 3
Again, osd journal = /dev/osd$id/journal is wrong, if you use this
directive, this must point to a filesystem because the jou
Hi,
I was wondering how I could update a key's metadata like the "Content-Type".
The solution on S3 seem to be to copy the key on itself and replacing
meta data. If I do that in ceph, will it work ? And more importantly,
will it be done "intelligently" (i.e. without copying the actual file
data a
Hi List,
I get reproducible this assertion, how can I help to debug it?
-martin
(Lese Datenbank ... 52246 Dateien und Verzeichnisse sind derzeit
installiert.)
Vorbereitung zum Ersetzen von linux-firmware 1.79 (durch
.../linux-firmware_1.79.1_all.deb) ...
Ersatz für linux-firmware wird entpackt
Hi Martin-
On Thu, 14 Feb 2013, Martin Mailand wrote:
> Hi List,
>
> I get reproducible this assertion, how can I help to debug it?
Can you describe the workload? Are the OSDs also running 0.56.2(+)? Any
other activity on the server side (data migration, OSD failure, etc.) that
may have cont
Merged. Thanks, Travis!
On Thu, 14 Feb 2013, Travis Rhoden wrote:
> Hey folks,
>
> I submitted a pull-request for some simple doc updates related to
> cephx and creating new keys/clients. Please take a look when
> possible.
>
> https://github.com/ceph/ceph/pull/56
>
> - Travis
> --
> To unsu
Thanks Wido for the clarifications.
I guessed this means that I can update the OSD cluster to 0.56, and client that
was compiled with the old librados2 0.48 should still be able to access the
cluster without any change. Client that compiled with the new librados2 0.56
(API level 0.48) has to
Hi Sage,
everything is on 0.56.2 and the cluster is healthy.
I can reproduce it with an apt-get upgrade within the vm, the vm os is
12.04. Most of the time the assertion happened when the firmware .deb is
updated. See the log in my first email.
But I use a custom build qemu version (1.4-rc1), whic
Hi Sage,
block device level. We plan to implement an incremental backup function
for the relative change between two snapshots (or a snapshot and the
head). It's O(n) the size of the device vs the number of files, but
should be more efficient for all but the most sparse of images. The
impl
Hey Danny,
I've merged in most of these (commit
ffda2eab4695af79abdc9ed9bf001c3cd662a1f2) but had comments on a
couple:
d99764e8c72a24eaba0542944f497cc2d9e154b4 is a patch on gtest. We did
import that wholesale into our repository as that's what they
recommend,b but I'd prefer to get patches by re-
On Thu, Feb 14, 2013 at 11:39 AM, GitHub wrote:
> Branch: refs/heads/master
> Home: https://github.com/ceph/ceph
> Commit: e330b7ec54f89ca799ada376d5615e3c1dfc54f0
>
> https://github.com/ceph/ceph/commit/e330b7ec54f89ca799ada376d5615e3c1dfc54f0
> Author: Sage Weil
> Date: 201
On Thu, 14 Feb 2013, Gregory Farnum wrote:
> In the tests I ran last night on this branch I saw some Valgrind
> warnings in the OSDs and Monitors, but I couldn't figure out any way
> for this series to have caused them so I assume they're latent and pop
> up occasionally in master? In any case, ple
Hi Jens-
On Thu, 14 Feb 2013, Jens Kristian S?gaard wrote:
> Hi Sage,
>
> > block device level. We plan to implement an incremental backup function for
> > the relative change between two snapshots (or a snapshot and the head).
> > It's O(n) the size of the device vs the number of files, but sho
Sage sent out an early draft of what we were thinking about doing for
fsck on CephFS at the beginning of the week, but it was a bit
incomplete and still very much a work in progress. I spent a good
chunk of today thinking about it more so that we can start planning
ticket-level chunks of work. The
On 2013-02-12, Chris Dunlop wrote:
> Hi,
>
> What are likely causes for "slow requests" and "monclient: hunting for new
> mon" messages? E.g.:
>
> 2013-02-12 16:27:07.318943 7f9c0bc16700 0 monclient: hunting for new mon
> ...
> 2013-02-12 16:27:45.892314 7f9c13c26700 0 log [WRN] : 6 slow request
On Fri, 15 Feb 2013, Chris Dunlop wrote:
> On 2013-02-12, Chris Dunlop wrote:
> > Hi,
> >
> > What are likely causes for "slow requests" and "monclient: hunting for new
> > mon" messages? E.g.:
> >
> > 2013-02-12 16:27:07.318943 7f9c0bc16700 0 monclient: hunting for new mon
> > ...
> > 2013-02-12
Alexandre and I have been working on adding basic dm-crypt support to
ceph-disk-prepare/activate. At this point it is working reasonably well,
but before we move forward I thought I'd see if anyone has
feedback/comments on the implementation.
The initial goals are very simple: transparently dm
On 02/14/2013 12:53 PM, Sage Weil wrote:
Hi Jens-
On Thu, 14 Feb 2013, Jens Kristian S?gaard wrote:
Hi Sage,
block device level. We plan to implement an incremental backup function for
the relative change between two snapshots (or a snapshot and the head).
It's O(n) the size of the device vs
G'day,
In an otherwise seemingly healthy cluster (ceph 0.56.2), what might cause the
mons to lose touch with the osds?
I imagine a network glitch could cause it, but I can't see any issues in any
other system logs on any of the machines on the network.
Having (mostly?) resolved my previous "slow
Hi Chris,
On Fri, 15 Feb 2013, Chris Dunlop wrote:
> G'day,
>
> In an otherwise seemingly healthy cluster (ceph 0.56.2), what might cause the
> mons to lose touch with the osds?
>
> I imagine a network glitch could cause it, but I can't see any issues in any
> other system logs on any of the mac
24 matches
Mail list logo