I don't need to redistribute data after OSD failure. All I want to do in
this test setup is to keep data safe in RO after such failure.
Paweł
W dniu 9.11.2022 o 17:09, Danny Webb pisze:
With a 3 osd pool it's not possible for data to be redistributed on failure of
an OSD. with a K=2,M=1 va
If I start to use all available space that pool can offer (4.5T) and
first OSD (2.7T) fails, I'm sure I'll end up with lost data since it's
not possible to fit 4.5T on 2 remaining drives with total raw capacity
of 3.6T.
I'm wondering why ceph isn't complaining now. I thought it should place
d
I guess it's not an issue in larger scenarios, but I hope there's some
feature to inform user that pool is not safe.
And what is the general rule? If k+m = #OSDs than do not use disks of
different size?
P.
W dniu 8.11.2022 o 15:25, Paweł Kowalski pisze:
Hi,
I've set
Hi,
I've set up a minimal EC setup - 3 OSDs, k=2, m=1:
root@skarb:~# ceph osd df
ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META
AVAIL %USE VAR PGS STATUS
[...]
9 low_hdd 2.72849 1.0 2.7 TiB 632 GiB 631 GiB 121 KiB 1.6
GiB 2.1 TiB 22.62 0.
I had to check logs once again to find out what I exactly did...
1. Destroyed 2 OSDs from host pirat and recreated them, but backfilling
was still in progress:
2022-10-26T13:22:13.744545+0200 mgr.skarb (mgr.40364478) 93039 : cluster
[DBG] pgmap v94205: 285 pgs: 2
active+undersized+degraded+
for the
affected pool? Your osd tree could help as well to figure out what
happened.
Zitat von Paweł Kowalski :
Hello,
2 PG's were stuck in "inactive state". I'm trying to find out why
this happened. Here's what I found in logs (only what I think is
important):
2
Hello,
2 PG's were stuck in "inactive state". I'm trying to find out why this
happened. Here's what I found in logs (only what I think is important):
2022-10-27T22:39:29.707362+0200 mgr.skarb (mgr.40364478) 152930 :
cluster [DBG] pgmap v154892: 410 pgs: 1 active+remapped+backfilling, 2
activ
