[ceph-users] Re: OSD Crash in recovery: SST file contains data beyond the point of corruption.

2022-09-19 Thread Igor Fedotov

Hi Benjamin,

good to know, thanks for the feedback.

Curious which exact mode (kSkipAnyCorruptedRecords or 
kTolerateCorruptedTailRecords) did the trick?



Regards,

Igor

On 9/17/2022 4:57 PM, Benjamin Naber wrote:

Hey Igor,

i just wanted to thank you for the help!
With the Flag you told me, i was able to brind up the OSD Container, 
then i marked it out and let ceph rebalance the PG´s and Objects to 
other OSD´s.
Yesterday all PG´s got avaiable again i could wipe the failed OSD 
drive an created a new one. Now everything works without the rocksdb 
flag and seems to fine!

THANK YOU SO MUCH!

Regards

Ben

Am Dienstag, September 13, 2022 11:26 CEST, schrieb Igor Fedotov 
:


Hi Benjamin,

sorry for the confusion this should be kSkipAnyCorruptedRecords not 
kSkipAnyCorruptedRecord


Thanks,

Igor

On 9/12/2022 11:26 PM, Benjamin Naber wrote:

Hi Igor,

looks like the setting wont work, the container now starts with a 
different error message that the setting is an invalid argument.
Did i something wrong by setting: /ceph config set osd.4 
bluestore_rocksdb_options_annex 
"wal_recovery_mode=kSkipAnyCorruptedRecord"/ ?


debug 2022-09-12T20:20:45.044+ 8714e040  1 bluefs 
add_block_device bdev 1 path /var/lib/ceph/osd/ceph-4/block size 2.7 TiB

debug 2022-09-12T20:20:45.044+ 8714e040  1 bluefs mount
debug 2022-09-12T20:20:45.044+ 8714e040  1 bluefs _init_alloc 
shared, id 1, capacity 0x2baa100, block size 0x1
debug 2022-09-12T20:20:45.608+ 8714e040  1 bluefs mount 
shared_bdev_used = 0
debug 2022-09-12T20:20:45.608+ 8714e040  1 
bluestore(/var/lib/ceph/osd/ceph-4) _prepare_db_environment set 
db_paths to db,2850558889164 db.slow,2850558889164
debug 2022-09-12T20:20:45.608+ 8714e040 -1 rocksdb: Invalid 
argument: No mapping for enum : wal_recovery_mode
debug 2022-09-12T20:20:45.608+ 8714e040 -1 rocksdb: Invalid 
argument: No mapping for enum : wal_recovery_mode
debug 2022-09-12T20:20:45.608+ 8714e040  1 rocksdb: do_open 
load rocksdb options failed
debug 2022-09-12T20:20:45.608+ 8714e040 -1 
bluestore(/var/lib/ceph/osd/ceph-4) _open_db erroring opening db:

debug 2022-09-12T20:20:45.608+ 8714e040  1 bluefs umount
debug 2022-09-12T20:20:45.608+ 8714e040  1 
bdev(0xec8e3c00 /var/lib/ceph/osd/ceph-4/block) close
debug 2022-09-12T20:20:45.836+ 8714e040  1 
bdev(0xec8e2400 /var/lib/ceph/osd/ceph-4/block) close
debug 2022-09-12T20:20:46.088+ 8714e040 -1 osd.4 0 OSD:init: 
unable to mount object store
debug 2022-09-12T20:20:46.088+ 8714e040 -1  ** ERROR: osd 
init failed: (5) Input/output error


Regards and many thanks for the help!

Ben
Am Montag, September 12, 2022 21:14 CEST, schrieb Igor Fedotov 
:

Hi Benjamin,

honestly the following advice is unlikely to help but you may want to
try to set bluestore_rocksdb_options_annex to one of the following 
options:


- wal_recovery_mode=kTolerateCorruptedTailRecords

- wal_recovery_mode=kSkipAnyCorruptedRecord


The indication that the setting is in effect would be the respective
value at the end of following log line:

debug 2022-09-12T17:37:05.574+ a8316040 4 rocksdb:
Options.wal_recovery_mode: 2


It should get 0 and 3 respectively.


Hoe this helps,

Igor


On 9/12/2022 9:09 PM, Benjamin Naber wrote:
> Hi Everybody,
>
> im struggeling now a couple of days with a degraded cehp cluster.
> Its a simple 3 node Cluster with 6 OSD´s, 3 SSD based, 3 HDD 
based. A couple of days ago one of the nodes crashed. in case of 
Hardisk failure, i replaces the hard disk and the recovery process 
started without any issues.
> As the node was still recovering the new replaced OSD drive was 
switched to backfillfull. And this is where the pain stareted. I 
added another node bought a harddrive and wiped the replacement OSD.
> The Cluster then was a 4 node sized cluster with 3 OSD´s for the 
SSD pool and 4 OSD´s for the HDD pool.
> Then i started the recovery process from beginning. Ceph has also 
started at this point a reassingment of missplaced objects.
> Then a power failure to one of the remaining nodes happend and now 
im stucking with a degraded Cluster and  49 pgs inactive, 3 pgs 
incomplete.
> The OSD Container on the power failure node dindt come up anymore 
in case of rocksdb error. Any advice how the recover the corrupt 
rocksdb ?

> Container Log and rocksdb error:
>
> https://pastebin.com/gvGJdubx
>
> Regards an thanks for your help!
>
> Ben
>
>
> --
> ___
> Diese E-mail einschließlich eventuell angehängter Dateien enthält 
vertrauliche und / oder rechtlich geschützte Informationen. Wenn Sie 
nicht der richtige Adressat sind und diese E-mail irrtümlich 
erhalten haben, dürfen Sie weder den Inhalt dieser E-mail nutzen 
noch dürfen Sie die eventuell angehängten Dateien öffnen und auch 
keine Kopie fertigen oder den Inhalt weitergeben / verbreiten. Bitte 
verständigen Sie den Absender und l

[ceph-users] Re: OSD Crash in recovery: SST file contains data beyond the point of corruption.

2022-09-13 Thread Igor Fedotov

Hi Benjamin,

sorry for the confusion this should be kSkipAnyCorruptedRecords not 
kSkipAnyCorruptedRecord



Thanks,

Igor

On 9/12/2022 11:26 PM, Benjamin Naber wrote:

Hi Igor,

looks like the setting wont work, the container now starts with a 
different error message that the setting is an invalid argument.
Did i something wrong by setting: /ceph config set osd.4 
bluestore_rocksdb_options_annex 
"wal_recovery_mode=kSkipAnyCorruptedRecord"/ ?


debug 2022-09-12T20:20:45.044+ 8714e040  1 bluefs 
add_block_device bdev 1 path /var/lib/ceph/osd/ceph-4/block size 2.7 TiB

debug 2022-09-12T20:20:45.044+ 8714e040  1 bluefs mount
debug 2022-09-12T20:20:45.044+ 8714e040  1 bluefs _init_alloc 
shared, id 1, capacity 0x2baa100, block size 0x1
debug 2022-09-12T20:20:45.608+ 8714e040  1 bluefs mount 
shared_bdev_used = 0
debug 2022-09-12T20:20:45.608+ 8714e040  1 
bluestore(/var/lib/ceph/osd/ceph-4) _prepare_db_environment set 
db_paths to db,2850558889164 db.slow,2850558889164
debug 2022-09-12T20:20:45.608+ 8714e040 -1 rocksdb: Invalid 
argument: No mapping for enum : wal_recovery_mode
debug 2022-09-12T20:20:45.608+ 8714e040 -1 rocksdb: Invalid 
argument: No mapping for enum : wal_recovery_mode
debug 2022-09-12T20:20:45.608+ 8714e040  1 rocksdb: do_open 
load rocksdb options failed
debug 2022-09-12T20:20:45.608+ 8714e040 -1 
bluestore(/var/lib/ceph/osd/ceph-4) _open_db erroring opening db:

debug 2022-09-12T20:20:45.608+ 8714e040  1 bluefs umount
debug 2022-09-12T20:20:45.608+ 8714e040  1 bdev(0xec8e3c00 
/var/lib/ceph/osd/ceph-4/block) close
debug 2022-09-12T20:20:45.836+ 8714e040  1 bdev(0xec8e2400 
/var/lib/ceph/osd/ceph-4/block) close
debug 2022-09-12T20:20:46.088+ 8714e040 -1 osd.4 0 OSD:init: 
unable to mount object store
debug 2022-09-12T20:20:46.088+ 8714e040 -1  ** ERROR: osd init 
failed: (5) Input/output error


Regards and many thanks for the help!

Ben
Am Montag, September 12, 2022 21:14 CEST, schrieb Igor Fedotov 
:

Hi Benjamin,

honestly the following advice is unlikely to help but you may want to
try to set bluestore_rocksdb_options_annex to one of the following 
options:


- wal_recovery_mode=kTolerateCorruptedTailRecords

- wal_recovery_mode=kSkipAnyCorruptedRecord


The indication that the setting is in effect would be the respective
value at the end of following log line:

debug 2022-09-12T17:37:05.574+ a8316040 4 rocksdb:
Options.wal_recovery_mode: 2


It should get 0 and 3 respectively.


Hoe this helps,

Igor


On 9/12/2022 9:09 PM, Benjamin Naber wrote:
> Hi Everybody,
>
> im struggeling now a couple of days with a degraded cehp cluster.
> Its a simple 3 node Cluster with 6 OSD´s, 3 SSD based, 3 HDD based. 
A couple of days ago one of the nodes crashed. in case of Hardisk 
failure, i replaces the hard disk and the recovery process started 
without any issues.
> As the node was still recovering the new replaced OSD drive was 
switched to backfillfull. And this is where the pain stareted. I 
added another node bought a harddrive and wiped the replacement OSD.
> The Cluster then was a 4 node sized cluster with 3 OSD´s for the 
SSD pool and 4 OSD´s for the HDD pool.
> Then i started the recovery process from beginning. Ceph has also 
started at this point a reassingment of missplaced objects.
> Then a power failure to one of the remaining nodes happend and now 
im stucking with a degraded Cluster and  49 pgs inactive, 3 pgs 
incomplete.
> The OSD Container on the power failure node dindt come up anymore 
in case of rocksdb error. Any advice how the recover the corrupt 
rocksdb ?

> Container Log and rocksdb error:
>
> https://pastebin.com/gvGJdubx
>
> Regards an thanks for your help!
>
> Ben
>
>
> --
> ___
> Diese E-mail einschließlich eventuell angehängter Dateien enthält 
vertrauliche und / oder rechtlich geschützte Informationen. Wenn Sie 
nicht der richtige Adressat sind und diese E-mail irrtümlich erhalten 
haben, dürfen Sie weder den Inhalt dieser E-mail nutzen noch dürfen 
Sie die eventuell angehängten Dateien öffnen und auch keine Kopie 
fertigen oder den Inhalt weitergeben / verbreiten. Bitte verständigen 
Sie den Absender und löschen Sie diese E-mail und eventuell 
angehängte Dateien umgehend.

> ___
> ceph-users mailing list -- ceph-users@ceph.io
> To unsubscribe send an email to ceph-users-le...@ceph.io

--
Igor Fedotov
Ceph Lead Developer

Looking for help with your Ceph cluster? Contact us at https://croit.io

croit GmbH, Freseniusstr. 31h, 81247 Munich
CEO: Martin Verges - VAT-ID: DE310638492
Com. register: Amtsgericht Munich HRB 231263
Web: https://croit.io | YouTube: https://goo.gl/PGE1Bx




--
___
Benjamin Naber • Holzstraße 7 • D-73650 Winterbach
Mobil: +49 (0) 152.34087809
E-Mail: benjamin.na...@coder

[ceph-users] Re: OSD Crash in recovery: SST file contains data beyond the point of corruption.

2022-09-12 Thread Igor Fedotov

Hi Benjamin,

honestly the following advice is unlikely to help but you may want to 
try to set bluestore_rocksdb_options_annex to one of the following options:


- wal_recovery_mode=kTolerateCorruptedTailRecords

- wal_recovery_mode=kSkipAnyCorruptedRecord


The indication that the setting is in effect would be the respective 
value at the end of following log line:


debug 2022-09-12T17:37:05.574+ a8316040 4 rocksdb: 
Options.wal_recovery_mode: 2



It should get 0 and 3 respectively.


Hoe this helps,

Igor


On 9/12/2022 9:09 PM, Benjamin Naber wrote:

Hi Everybody,

im struggeling now a couple of days with a degraded cehp cluster.
Its a simple 3 node Cluster with 6 OSD´s, 3 SSD based, 3 HDD based. A couple of 
days ago one of the nodes crashed. in case of Hardisk failure, i replaces the 
hard disk and the recovery process started without any issues.
As the node was still recovering the new replaced OSD drive was switched to 
backfillfull. And this is where the pain stareted. I added another node bought 
a harddrive and wiped the replacement OSD.
The Cluster then was a 4 node sized cluster with 3 OSD´s for the SSD pool and 4 
OSD´s for the HDD pool.
Then i started the recovery process from beginning. Ceph has also started at 
this point a reassingment of missplaced objects.
Then a power failure to one of the remaining nodes happend and now im stucking 
with a degraded Cluster and  49 pgs inactive, 3 pgs incomplete.
The OSD Container on the power failure node dindt come up anymore in case of 
rocksdb error. Any advice how the recover the corrupt rocksdb ?
Container Log and rocksdb error:

https://pastebin.com/gvGJdubx

Regards an thanks for your help!

Ben


--
___
Diese E-mail einschließlich eventuell angehängter Dateien enthält vertrauliche 
und / oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige 
Adressat sind und diese E-mail irrtümlich erhalten haben, dürfen Sie weder den 
Inhalt dieser E-mail nutzen noch dürfen Sie die eventuell angehängten Dateien 
öffnen und auch keine Kopie fertigen oder den Inhalt weitergeben / verbreiten. 
Bitte verständigen Sie den Absender und löschen Sie diese E-mail und eventuell 
angehängte Dateien umgehend.
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io


--
Igor Fedotov
Ceph Lead Developer

Looking for help with your Ceph cluster? Contact us at https://croit.io

croit GmbH, Freseniusstr. 31h, 81247 Munich
CEO: Martin Verges - VAT-ID: DE310638492
Com. register: Amtsgericht Munich HRB 231263
Web: https://croit.io | YouTube: https://goo.gl/PGE1Bx

___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io