Did you shut down the node with 2 mon?
I think it might be impossible to have redundancy with only 2 node, paxos
quorum is the reason:
Say you have N (N=2K+1) monitors, you always have a node(let's named it node A)
with majority number of MONs(>= K+1), another node(node B) with minority number
Hi,
My OSDs with btrfs are down on one node. I found the cluster in this state:
cephadmin@ceph1:~$ ceph osd tree
# idweight type name up/down reweight
-1 10.88 root default
-2 5.44host ceph1
0 2.72osd.0 down0
1 2.72
Hi,
Here is my memory output. I use HP Microservers with 2GB RAM. Swap is
500MB on SSD disk.
cephadmin@ceph1:~$ free
total used free sharedbuffers cached
Mem: 18857201817860 67860 0 32 694552
-/+ buffers/cache:1123276 762
Hi.
Correction. My SWAP is 3GB on SSD disk. I dont use th nodes for client
stuff.
Thx Jiri
On 5/01/2015 01:21, Jiri Kanicky wrote:
Hi,
Here is my memory output. I use HP Microservers with 2GB RAM. Swap is
500MB on SSD disk.
cephadmin@ceph1:~$ free
total used free
On 2015-01-04 08:21, Jiri Kanicky wrote:
More googling took me to the following post:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2014-June/040279.html
Linux 3.14.1 is affected by serious Btrfs regression(s) that were fixed
in
later releases.
Unfortunately even latest Linux can cra
Hi there,
I did something stupid while growing an rbd image. I accidentally
mistook the units of the resize command for bytes instead of megabytes
and grew an rbd image to 650PB instead of 650GB. This all happened
instantaneously enough, but trying to rectify the mistake is not going
nearly a
Hi there,
I did something stupid while growing an rbd image. I accidentally
mistook the units of the resize command for bytes instead of megabytes
and grew an rbd image to 650PB instead of 650GB. This all happened
instantaneously enough, but trying to rectify the mistake is not going
nearly a
Hi,
If its the only think in your pool, you could try deleting the pool
instead.
I found that to be faster in my testing; I had created 500TB when I
meant to create 500GB.
Note for the Devs: I would be nice if rbd create/resize would accept
sizes with units (i.e. MB GB TB PB, etc).
On
Hi.
I have been experiencing same issues on both nodes over the past 2 days
(never both nodes at the same time). It seems the issue occurs after
some time when copying a large number of files to CephFS on my client
node (I dont use RBD yet).
These are new HP servers and the memory does not
Hi.
Do you know how to tell that the option "filestore btrfs snap = false"
is set?
Thx Jiri
On 5/01/2015 02:25, Jiri Kanicky wrote:
Hi.
I have been experiencing same issues on both nodes over the past 2
days (never both nodes at the same time). It seems the issue occurs
after some time w
On 01/04/15 16:25, Jiri Kanicky wrote:
> Hi.
>
> I have been experiencing same issues on both nodes over the past 2
> days (never both nodes at the same time). It seems the issue occurs
> after some time when copying a large number of files to CephFS on my
> client node (I dont use RBD yet).
>
>
Hello,
Is there an answer to why this is happening, I am facing the same issue, I
have the non-system user replicated to the slave zone, but still getting
403, the same thing happening when I am replicating from the master zone of
master region to master zone of secondary region.
I am using swift,
On Sunday, January 4, 2015, Dyweni - Ceph-Users <6exbab4fy...@dyweni.com>
wrote:
> Hi,
>
> If its the only think in your pool, you could try deleting the pool
> instead.
>
> I found that to be faster in my testing; I had created 500TB when I meant
> to create 500GB.
>
> Note for the Devs: I would
Thanks Jake, however, I need to shrink the image, not delete it as it
contains a live customer image. Is it possible to manually edit the RBD
header to make the necessary adjustment?
Regards,
Edwin Peer
On 01/04/2015 08:48 PM, Jake Young wrote:
On Sunday, January 4, 2015, Dyweni - Ceph-User
Happy holiday everyone,
TL;DR: Hardware corruption is really bad, if btrfs-restore work,
kernel Btrfs can!
I'm cross-posting this message since the root cause for this problem
is the Ceph RBD device however, my main concern is data loss from a
BTRFS filesystem hosted on this device.
I'm running
On Sun, Jan 4, 2015 at 10:43 PM, Edwin Peer wrote:
> Thanks Jake, however, I need to shrink the image, not delete it as it
> contains a live customer image. Is it possible to manually edit the RBD
> header to make the necessary adjustment?
>
Technically speaking, yes - the size information is con
Also, which rbd objects are of interest?
ganymede ~ # rados -p client-disk-img0 ls | wc -l
1672636
And, all of them have cryptic names like:
rb.0.ff53.3d1b58ba.e6ad
rb.0.6d386.1d545c4d.00011461
rb.0.50703.3804823e.1c28
rb.0.1073e.3d1b58ba.b715
rb.0.1d76.2ae8944a.00
You could use rbd info to see the block_name_prefix, the object
name consist like ., so for example,
rb.0.ff53.3d1b58ba.e6ad should be the th object of the volume
with block_name_prefix rb.0.ff53.3d1b58ba.
$ rbd info huge
rbd image 'huge':
size 1024 TB in 26843
On Fri, 02 Jan 2015 06:38:49 +1000 Lindsay Mathieson wrote:
> Expanding my tiny ceph setup from 2 OSD's to six, and two extra SSD's
> for journals (IBM 530 120GB)
>
> Yah, I know the 5300's would be much better
>
S5700's really, if you look at the prices and especially TBW/$.
> Assuming I
i have tried ' ceph mds newfs 1 0 --yes-i-really-mean-it'but not fix
the problem
2014-12-30 17:42 GMT+07:00 Lindsay Mathieson :
> On Tue, 30 Dec 2014 03:11:25 PM debian Only wrote:
>
> > ceph 0.87 , Debian 7.5, anyone can help ?
>
> >
>
> > 2014-12-29 20:03 GMT+07:00 debian Only :
>
> > i
Did you remove the mds.0 entry from ceph.conf?
On 5 January 2015 at 14:13, debian Only wrote:
> i have tried ' ceph mds newfs 1 0 --yes-i-really-mean-it'but not fix
> the problem
>
> 2014-12-30 17:42 GMT+07:00 Lindsay Mathieson
> :
>
>> On Tue, 30 Dec 2014 03:11:25 PM debian Only wrote:
>>
On 5 January 2015 at 13:02, Christian Balzer wrote:
> On Fri, 02 Jan 2015 06:38:49 +1000 Lindsay Mathieson wrote:
>
>
> If you research the ML archives you will find that cache tiering currently
> isn't just fraught with peril (there are bugs) but most importantly isn't
> really that fast.
>
Ya
Well I upgraded my cluster over the weekend :)
To each node I added:
- Intel SSD 530 for journals
- 2 * 1TB WD Blue
So two OSD Nodes had:
- Samsung 840 EVO SSD for Op. Sys.
- Intel 530 SSD for Journals (10GB Per OSD)
- 3TB WD Red
- 1 TB WD Blue
- 1 TB WD Blue
- Each disk weighted at 1.0
- Primary
Hi Lindsay,
On 05.01.2015 06:52, Lindsay Mathieson wrote:
> ...
> So two OSD Nodes had:
> - Samsung 840 EVO SSD for Op. Sys.
> - Intel 530 SSD for Journals (10GB Per OSD)
> - 3TB WD Red
> - 1 TB WD Blue
> - 1 TB WD Blue
> - Each disk weighted at 1.0
> - Primary affinity of the WD Red (slow) set to
24 matches
Mail list logo
