Re: HELP! Upgrading monitors from 14.2.22 to 16.2.7 immediately crashes in FSMap::decode()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Sam.

> On 21 Mar 2022, at 17:29, Clippinger, Sam <Sam.Clippinger@xxxxxxxxxx> wrote:
> 
> Pacific but I could step through an Octopus -> Pacific process just fine.  Does that seem like a valid test?  I tried updating a production monitor to Octopus first this weekend and couldn’t update to Pacific – did it fail because I didn’t update all of the monitors to Octopus before trying Pacific?

I did upgrade all monitors to Octopus before moving on to Pacific, but didn’t try with a single one.


> I’m concerned about the other issues you’re seeing though.  Are you having to restart your monitors constantly to control the data size, or was that a one-time thing?

I only needed to restart once after the whole cluster was updated. So far that issue has not come up again. Basically the osd maps were not being reclaimed, probably because a lot of OSDs were restarted in a short amount of time for the upgrade.


> Is it common for scrubs to stop working or is that a rare problem?  The ticket doesn’t seem to be getting much attention, I’m not sure how to interpret that.

It doesn’t seem to be common, although there are several reports. Nevertheless, since there is no workaround of even acknowledgement of the issue, it is a bit worrisome.


Best regards,
André
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux