Den mån 6 maj 2019 kl 10:03 skrev Marc Roos <[email protected]>:
> > Yes but those 'changes' can be relayed via the kernel rbd driver not? > Besides I don't think you can move a rbd block device being used to a > different pool anyway. > > No, but you can move the whole pool, which takes all RBD images with it. > On the manual page [0] there is nothing mentioned about configuration > settings needed for rbd use. Nor for ssd. They are also using in the > example the virtio/vda, while I learned here that you should use the > virtio-scsi/sda. > > There are differences here, one is "tell guest to use virtio-scsi" that will allow TRIM from a guest to become a possibility to reclaim space on thin-provisioned RBD images, and that is probably a good thing. That doesn't mean the guest TRIM commands will pass on to the pool OSD storage sectors underneath. So you don't gain anything directly on the end devices in that regard to let a guest know that it currently is lying on SSDs or HDDs, because the guest will not be sending SSD commands to the real device. Inversely, the TRIMs sent from a guest would allow re-thinning on a HDD pool aswell, since it's not a factor of the underlying devices, but rather the ceph code and pool/rbd properties which are the same regardless. Also, if the guest makes other decisions based on if there is HDD or SSD underneath, those decisions can be wrong both ways, like "I was told its hdd and therefore I assume only X iops are possible" where the kvm librbd layer can cache tons of things for you, aswell as filestore OSD ram caches could give you awesome RAM-like write performance not seen on normal HDDs ever. (at the risk of dataloss in the worst case) On the other hand, being told as a guest that there is SSD or NVME and deciding 100k iops should be the norm from now on would be equally wrong the other way around if your ceph network between the guest and OSDs prevent you from doing more than 1k iops. If you find out that there is no certain way to tell a guest about where it really is stored, that may actually be a conscious decision that is for the best. Let the guest try to do as much IO as it think it needs and get the results when they are ready. (a nod to Xen that likes to tell its guests they are on IDE drives so guests never send out more than one IO request at a time because IDE just don't have that concept, regardless of how fancy host you have with super-deep request queues and all... 8-/ ) -- May the most significant bit of your life be positive.
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
