Hi Dan,
I need to bring the affected OSDs up this week. Would be great if
you could take a look at this case or let me know if you don't have
time.
Best regards,
=================
Frank Schilder
AIT Risø Campus
Bygning 109, rum S14
________________________________________
From: Frank Schilder <frans@xxxxxx>
Sent: Friday, November 8, 2024 6:13 PM
To: Dan van der Ster
Cc: ceph-users@xxxxxxx
Subject: Re: failed to load OSD map for epoch 2898146,
got 0 bytes
Hi Dan,
I have collected a 134M log file (11M compressed) of the startup
with debug_osd=20/20. Do you have access to the upload area of the
ceph-devs (the ceph-post-file destination)? If not, any preferred
way I can send it to you?
To execute the ceph-objectstore-tool mount command it looks like I
need to activate the OSD first, is this correct? Can I just use
"umount" to unmount again?
On a side note, I noticed something strange. We have a containerized
deployment and to have everything at the same version we also run a
container ceph_adm for admin purposes. We bind-mount /var/lib/ceph
into all containers. I now observed that for OSDs we manually
recreated with "ceph-volume batch" inside ceph_adm their data path
folders remain mounted as in:
tmpfs on /var/lib/ceph/osd/ceph-110 type tmpfs (rw,relatime,seclabel)
ceph-volume batch apparently leaves this tmpfs mount behind instead
of cleaning it up. For these OSDs we now have the data dir mounted
in two different containers (its a double mount). Its the first time
I noticed that, we never had any problems with that. Is it something
that I need to address somehow (like stop OSD, unmount in
adm_container or just restart the adm-container) or can I ignore it?
I guess in the future we need to execute an "osd deactivate" or
"umount" to clean this up after OSD creation.
Thanks for your help!
=================
Frank Schilder
AIT Risø Campus
Bygning 109, rum S14
________________________________________
From: Dan van der Ster <dan.vanderster@xxxxxxxxx>
Sent: Tuesday, October 22, 2024 11:56 PM
To: Frank Schilder
Cc: ceph-users@xxxxxxx
Subject: Re: failed to load OSD map for epoch 2898146,
got 0 bytes
Hi Frank,
I'm glad this thread is more about understanding what's going on, as
opposed to a quick fix. Normally people in this situation should just
zap and redeploy, like you said.
The next thing I'd do is fuse-mount the OSD and see which osdmaps it
has -- try to read them, etc. Does the OSD have the osdmap epoch it is
warning about in the logs?
ceph-objectstore-tool --data-path </path/to/osd> --op fuse --mountpoint /mnt
Inside /mnt you'll see the PGs and a meta folder, IIRC. Inside meta
you will find the osdmaps.
Cheers, dan
--
Dan van der Ster
CTO @ CLYSO
https://clyso.com | dan.vanderster@xxxxxxxxx
On Tue, Oct 22, 2024 at 12:14 AM Frank Schilder <frans@xxxxxx> wrote:
Hi Dan,
I don't remember exactly when I took them down. Maybe a month ago?
The reason was a fatal IO error due to connectivity issues. Its 2
SSDs with 4 OSDs each and they were installed in JBODs. We have 12
of those and, unfortunately, it seems that 3 have issues with SSDs
even though they have dedicated slots for SSD/NVMe drives. The
hallmark are SAS messages containing "blk_update" (usually
blk_update_request with a drive reset). Any attempts to fix that
(reseating, moving etc.) failed. We had like 40-50 messages per
disk per hour in the log, didn't impact performance though. So it
was a nuisance on the lower priority list.
Some time ago, maybe a month, in one of these JBODs the connection
finally gave up. For both SSDs at the same time. I'm pretty sure it
was a bus error and the disks are fine. I stopped these OSDs and
the data is recovered, no problems here. The disks are part of our
FS meta data pool and we have plenty, so there was no rush. They
store a ton of objects though and I try to avoid having a full
re-write of everything (life-time fetishist).
Yesterday, we started a major disk replacement operation after
evacuating about 40 HDDs. As part of this, we move all SSDs from
the JBODs to the servers and I tried to get these two disks up
yesterday with the result reported below. We are not done yet with
the maintenance operation and I can pull logs after we are done.
Possibly next week. We are not in a rush to get these disks back up
and I'm also prepared to just zap and redeploy these.
My interest with this case is along the lines "I would like to know
what is going on" and "is there a better way than zap+redeploy".
Others might be in a situation where they don't have the luxury of
all data being healthy and we have a chance to experiment without
any risk.
Best regards,
=================
Frank Schilder
AIT Risø Campus
Bygning 109, rum S14
________________________________________
From: Dan van der Ster <dan.vanderster@xxxxxxxxx>
Sent: Tuesday, October 22, 2024 12:04 AM
To: Frank Schilder
Cc: ceph-users@xxxxxxx
Subject: Re: failed to load OSD map for epoch 2898146,
got 0 bytes
Hi Frank,
Do you have some more info about these OSDs -- how long were they down
for? Were they down because of some IO errors?
Is it possible that the OSD thinks it stored those osdmaps but IO
errors are preventing them from being loaded?
I know the log is large, but can you share at least a snippet of when
this starts? Preferably with debug_osd = 10.
Thanks, Dan
--
Dan van der Ster
CTO @ CLYSO
https://clyso.com | dan.vanderster@xxxxxxxxx
On Mon, Oct 21, 2024 at 1:32 PM Frank Schilder <frans@xxxxxx> wrote:
>
> Hi Dan,
>
> maybe not. Looking at the output of
>
> grep -B 1 -e "2971464 failed to load OSD map for epoch 2898132"
/var/log/ceph/ceph-osd.1004.log
>
> that searches for lines that start a cycle and also print the
line before, there might be some progress, but I'm not sure:
>
> 2024-10-21T17:41:40.173+0200 7fad509a1700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898208, got 0 bytes
> 2024-10-21T17:41:40.173+0200 7fad4a194700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> --
> 2024-10-21T17:41:40.610+0200 7fad519a3700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898678, got 0 bytes
> 2024-10-21T17:41:40.610+0200 7fad4e19c700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> --
> 2024-10-21T17:41:41.340+0200 7fad4c198700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898293, got 0 bytes
> 2024-10-21T17:41:41.340+0200 7fad4f19e700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> --
> 2024-10-21T17:41:41.347+0200 7fad4e99d700 -1 osd.1004 2971464
failed to load OSD map for epoch 2899238, got 0 bytes
> 2024-10-21T17:41:41.347+0200 7fad4c999700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
>
> The loop seems to run longer and longer. Problem is though that
by the time it got here it already wrote like 1G log. The loop
seems to repeat over all epochs for each such iteration, so the log
output is quadratic in the number of epochs to catch up with. I
still have like 100000 to go and I doubt I have disks large enough
to collect the resulting logs. The logging probably also a total
performance killer.
>
> Is it possible to suppress the massive log spam so that I can let
it run until it is marked up? These messages seem not to be related
to a log level. If absolutely necessary, I could start the OSD
manually with logging to disk disabled.
>
> Thanks and best regards,
> =================
> Frank Schilder
> AIT Risø Campus
> Bygning 109, rum S14
>
> ________________________________________
> From: Dan van der Ster <dan.vanderster@xxxxxxxxx>
> Sent: Monday, October 21, 2024 9:03 PM
> To: Frank Schilder
> Cc: ceph-users@xxxxxxx
> Subject: Re: failed to load OSD map for epoch
2898146, got 0 bytes
>
> Hi Frank,
>
> Are you sure it's looping over the same epochs?
> It looks like that old osd is trying to catch up on all the osdmaps it
> missed while it was down. (And those old maps are probably trimmed
> from all the mons and osds, based on the "got 0 bytes" error).
> Eventually it should catch up to the current (e 2971464 according to
> your log), and then the PGs can go active.
>
> Cheers, Dan
>
> --
> Dan van der Ster
> CTO @ CLYSO
> https://clyso.com | dan.vanderster@xxxxxxxxx
>
>
>
>
> On Mon, Oct 21, 2024 at 9:13 AM Frank Schilder <frans@xxxxxx> wrote:
> >
> > Hi all,
> >
> > I have a strange problem on an octopus latest cluster. We had
a couple of SSD OSDs down for a while and brought them up today
again. For some reason, these OSDs don't come up and flood the log
with messages like
> >
> > osd.1004 2971464 failed to load OSD map for epoch 2898146, got 0 bytes
> >
> > These messages cycle through the same epochs over and over
again. I did not really fine too much help, there is an old thread
about a similar/the same problem on a home lab cluster, with new
OSDs though, I believe. I couldn't really find useful information.
The OSDs seem to boot fine and then end up in something like a
death loop. Below some snippets from the OSD log.
> >
> > Any hints appreciated.
> > Thanks and best regards,
> > Frank
> >
> > After OSD start, everything looks normal up to here:
> >
> > 2024-10-21T17:41:39.136+0200 7fad73cf6f00 0 osd.1004 2971464
load_pgs opened 205 pgs
> > 2024-10-21T17:41:39.140+0200 7fad73cf6f00 -1 osd.1004 2971464
log_to_monitors {default=true}
> > 2024-10-21T17:41:39.150+0200 7fad73cf6f00 -1 osd.1004 2971464
mon_cmd_maybe_osd_create fail: 'osd.1004 has already bound to class
'fs_meta', can not reset class to 'ssd'; use 'ceph osd crush
> > rm-device-class <id>' to remove old class first': (16) Device
or resource busy
> > 2024-10-21T17:41:39.155+0200 7fad519a3700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad511a2700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad511a2700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898133, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad511a2700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898134, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad511a2700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898135, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad511a2700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898136, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4f99f700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4f99f700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898133, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898132, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898133, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898134, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898135, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898136, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898137, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad73cf6f00 0 osd.1004 2971464
done with init, starting boot process
> > 2024-10-21T17:41:39.155+0200 7fad73cf6f00 1 osd.1004 2971464 start_boot
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898138, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898139, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898140, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898141, got 0 bytes
> > 2024-10-21T17:41:39.155+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898142, got 0 bytes
> > 2024-10-21T17:41:39.156+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898143, got 0 bytes
> > 2024-10-21T17:41:39.156+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898144, got 0 bytes
> > 2024-10-21T17:41:39.156+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898145, got 0 bytes
> > 2024-10-21T17:41:39.156+0200 7fad4b196700 -1 osd.1004 2971464
failed to load OSD map for epoch 2898146, got 0 bytes
> >
> >
> > These messages repeat over and over again with some others of
this form showing up every now and then:
> >
> > 2024-10-21T17:41:39.476+0200 7fad651ca700 4 rocksdb:
[db/compaction_job.cc:1332] [default] [JOB 12] Generated table
#82879: 76571 keys, 67866714 bytes
> > 2024-10-21T17:41:39.688+0200 7fad651ca700 4 rocksdb:
EVENT_LOG_v1 {"time_micros": 1729525299690000, "cf_name":
"default", "job": 12, "event": "table_file_creation",
"file_number": 82879, "file_size": 67866714, "table_properties":
{"data_size": 67111697, "index_size": 562601, "filter_size":
191557, "raw_key_size": 4823973, "raw_average_key_size": 63,
"raw_value_size": 62631087, "raw_average_value_size": 817,
"num_data_blocks": 15644, "num_entries": 76571,
"filter_policy_name": "rocksdb.BuiltinBloomFilter"}}
> >
> >
> > And another occasion:
> >
> > 2024-10-21T17:41:40.520+0200 7fad651ca700 4 rocksdb:
[db/compaction_job.cc:1332] [default] [JOB 12] Generated table
#82880: 76774 keys, 67868330 bytes
> > 2024-10-21T17:41:40.520+0200 7fad501a0700 -1 osd.1004 2971464
failed to load OSD map for epoch 2899234, got 0 bytes
> > 2024-10-21T17:41:40.520+0200 7fad501a0700 -1 osd.1004 2971464
failed to load OSD map for epoch 2899235, got 0 bytes
> > 2024-10-21T17:41:40.520+0200 7fad501a0700 -1 osd.1004 2971464
failed to load OSD map for epoch 2899236, got 0 bytes
> > 2024-10-21T17:41:40.520+0200 7fad651ca700 4 rocksdb:
EVENT_LOG_v1 {"time_micros": 1729525300521403, "cf_name":
"default", "job": 12, "event": "table_file_creation",
"file_number": 82880, "file_size": 67868330, "table_properties":
{"data_size": 67113021, "index_size": 562509, "filter_size":
191941, "raw_key_size": 4836742, "raw_average_key_size": 62,
"raw_value_size": 62623274, "raw_average_value_size": 815,
"num_data_blocks": 15630, "num_entries": 76774,
"filter_policy_name": "rocksdb.BuiltinBloomFilter"}}
> >
> > =================
> > Frank Schilder
> > AIT Risø Campus
> > Bygning 109, rum S14
> > _______________________________________________
> > ceph-users mailing list -- ceph-users@xxxxxxx
> > To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
