Ceph » RADOS

So we're going to put a huge asterisk here that the CIDR range of machines must be hard-rebooted, right? Otherwise whenever the unblocklist event comes in, any kernel mounts with dirty data will happily flush that out.

That was the rationale for the new generation number we discussed in various places including:

https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3FTOBHPZQGTEY3RHMO2EXKOLSP3SJGNW/

Also, I think compound blocklist commands should be supported as there will probably be several CIDR ranges involved.

Patrick Donnelly wrote:

So we're going to put a huge asterisk here that the CIDR range of machines must be hard-rebooted, right? Otherwise whenever the unblocklist event comes in, any kernel mounts with dirty data will happily flush that out.

I mean that’s only if you have on the force reconnect, which is a mount option, right? So anybody who wants to plan to use range blocklisting can just not use bad remounts. Or, they can arrange to reboot, which I get the impression is going to happen anyway since other layers need to do updates and fallbacks.

That was the rationale for the new generation number we discussed in various places including:

https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3FTOBHPZQGTEY3RHMO2EXKOLSP3SJGNW/

Yeah. That proposal isn’t gonna happen any time soon, if ever. I can knock this ticket out this or next week.

Also, I think compound blocklist commands should be supported as there will probably be several CIDR ranges involved.

Meh; we can handle three osdmap commits if needed but multiple ranges was specifically not part of the request — just a cluster with a single fixed range.

Greg Farnum wrote:

Patrick Donnelly wrote:

So we're going to put a huge asterisk here that the CIDR range of machines must be hard-rebooted, right? Otherwise whenever the unblocklist event comes in, any kernel mounts with dirty data will happily flush that out.

I mean that’s only if you have on the force reconnect, which is a mount option, right?

You mean recover_session=clean?

https://docs.ceph.com/en/pacific/man/8/mount.ceph/#basic

Not just in that scenario, no. The kernel has gotten better about not flushing dirty data when blocklisted. I'm not sure how safe it is at this time, Jeff would need to comment.

So anybody who wants to plan to use range blocklisting can just not use bad remounts.

You can't (yet) skip blocklisted superblocks. They stick around and prevent new mounts from even connecting. Jeff is working on a fix for that presently which will be upstream soon.

Or, they can arrange to reboot, which I get the impression is going to happen anyway since other layers need to do updates and fallbacks.

That was the rationale for the new generation number we discussed in various places including:

https://lists.ceph.io/hyperkitty/list/dev@ceph.io/thread/3FTOBHPZQGTEY3RHMO2EXKOLSP3SJGNW/

Yeah. That proposal isn’t gonna happen any time soon, if ever. I can knock this ticket out this or next week.

Also, I think compound blocklist commands should be supported as there will probably be several CIDR ranges involved.

Meh; we can handle three osdmap commits if needed but multiple ranges was specifically not part of the request — just a cluster with a single fixed range.

ACK.