Handzik, Joseph <joseph.t.handzik <at> hpe.com> writes: > > I was intentionally staying quiet to hear other opinions, but I agree that the same mechanisms I'm building > for LED operations could extend here (within Ceph of we want it to, but at the very least in libstoragemgmt). > > Naveen, if you have interest in helping push this along I'd encourage you to voice your interest over on the > libstoragemgmt GitHub: https://github.com/libstorage/libstoragemgmt > > Joe > > > > > This is all pretty relevant to Joe Handzik's stuff: > > https://github.com/joehandzik/ceph/commits/wip-hw-mgmt-cli > > http://www.spinics.net/lists/ceph-devel/msg30126.html > > > > The idea there though is to enable passing libstoragemgmt calls > > through the OSD, as opposed to arbitrary SCSI operations. > > > > Although libstoragemgmt is fairly young, I'm a fan of the idea that we > > could use it internally within Ceph, and then have the same tools/libs > > used by out-of-ceph management platforms when they want to do > > equivalent stuff while the OSD is offline. > > > > John > > > > > >>> I asked a related question in another post too: Can a physical disk > >>> (/dev/sda1) assigned to a ceph OSD object be continued to used by other > >>> apps in the system to issue I/O directly via (/dev/sda1) interface? Does > >>> ceph prevent it, as such operations may corrupt data? > >> > >> It depends on what privileges the other app has. If it's root or user > >> ceph, it can step all over the disk (and the rest of the system) and wreak > >> havoc. With the current backend, we are storing data as files, so you > >> could have other apps using other directories on the file system-- this is > >> generally a bad idea for real deployments, though, as performance and disk > >> utilization will be unpredictable. > >> > >> sage Thanks everyone for the inputs and clarifications. Looks like libstoragemgmt is key to lot of these feature. Will explore that next and add if any questions in the git. thanks, naveen -- 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