On Mon, 18 Aug 2014, Loic Dachary wrote: > On 18/08/2014 17:17, Sage Weil wrote: > > On Mon, 18 Aug 2014, Loic Dachary wrote: > >> Hi Ceph, > >> > >> In RHEL 6.5, is the following scenario possible : > >> > >> a) an OSD dlopen a shared library for erasure-code, > >> b) the shared library file is replaced while the OSD is running, > >> c) the OSD starts using the new file instead of the old one. > >> > >> It seems unlikely but it would explain a weird stack trace at > >> http://tracker.ceph.com/issues/9153#note-5 so I'm double checking ;-) > > > > I think this is possible and likely. We had similar problems with the > > rados classes and eventually just made them load all available plugins on > > startup (and also on demand in case one is installed later). > > > > The simplest thing is probably to do that here as well... > > This will not solve the upgrade problem for Firefly daemons which are > are already running, unfortunately. Stopping the daemons while the > package is being upgraded seems safer and more generic (see the other > thread). Or are there issues with this approach ? Operationally it is not something people want to do. Usually admins upgrade and then do the restarts in a controlled way. At least, that's what I've heard anecdotally. FWIW the crash is also something that testing turns up but is unlikely to happen in production. In testing, the workload is just starting when we start upgrading so the plugins haven't always loaded. In production, it is unlikely that a user will be *just* starting to use the EC features right as they are also doing an upgrade. Unless they forgot to restart daemons... sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
