I added an explanation of our use case to the tracker. Best regards, ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14 ________________________________________ From: Frank Schilder <frans@xxxxxx> Sent: 15 June 2022 15:59:15 To: Ilya Dryomov Cc: ceph-users@xxxxxxx Subject: Re: rbd resize thick provisioned image Hi Ilya, thanks for your explanations. > There are other issues with it: bluestore compression, if enabled, would interfere with it, for example. Yes, and I would expect from a ceph admin to understand that and disable any such option. So its not an argument not to have it but rather to "know what you are doing". Similarly, EC overwrites can screw this up, it only works with plain replicated pools as intended. > "dd if=/dev/zero bs=<object size> ..." for the grown area is a perfectly fine workaround. ... except for the obvious disaster problem of a typo in the destination's start address to avoid overwriting the valuable data at the beginning. I would very much prefer a command that is smart enough to fill in the missing bits only. Shame that your request has not been looked at. I will add a bit of information and hope it gets picked up. I cannot imagine this to be difficult at all. Best regards, ================= Frank Schilder AIT Risø Campus Bygning 109, rum S14 ________________________________________ From: Ilya Dryomov <idryomov@xxxxxxxxx> Sent: 15 June 2022 15:46:25 To: Frank Schilder Cc: Eugen Block; ceph-users@xxxxxxx Subject: Re: Re: rbd resize thick provisioned image On Wed, Jun 15, 2022 at 3:21 PM Frank Schilder <frans@xxxxxx> wrote: > > Hi Eugen, > > in essence I would like the property "thick provisioned" to be sticky after creation and apply to any other operation that would be affected. > > To answer the use-case question: this is a disk image on a pool designed for predictable high-performance. On images on this pool we need to avoid any latency spikes due to on-demand allocation of non-provisioned objects. It is kind of strange that the rbd cli API is incomplete with regard to the thick provision property. Hi Frank, Yeah, it appears to be an omission. I filed [1] to get that addressed one day. RBD "thick provisioning" is a bit of odd ball feature. There are other issues with it: bluestore compression, if enabled, would interfere with it, for example. In general, the "thickness" (really just a bunch of zeroes written to the image on your behalf) isn't safe-guarded against any kind of compression-like optimization on the backend. > > I'm not sure if a flatten will have the desired effect. It just merges all snapshots, which does not require to allocate unallocated objects if they are not present in any snapshot. An un-sparsify image would do that. Did anyone find a reasonable work-around except maybe a dd after the end of the existing objects? Or a dd of the disk image onto itself? "dd if=/dev/zero bs=<object size> ..." for the grown area is a perfectly fine workaround. [1] https://tracker.ceph.com/issues/56064 Thanks, Ilya > > Best regards, > ================= > Frank Schilder > AIT Risø Campus > Bygning 109, rum S14 > > ________________________________________ > From: Eugen Block <eblock@xxxxxx> > Sent: 15 June 2022 14:54:54 > To: ceph-users@xxxxxxx > Subject: Re: rbd resize thick provisioned image > > So basically, you need the reverse sparsify command, right? ;-) > I only find several mailing list thready asking why someone would want > thick-provisioning but it happened eventually. I suppose cloning and > flattening the resulting image is not a desirable workaround. > > > Zitat von Frank Schilder <frans@xxxxxx>: > > > Hi all, > > > > I need to increase the size of images created with > > --thick-provision. Using resize will just change the provisioned > > size, but not allocate/initialize the additional space. I seem to be > > unable to find an option that will maintain thick provisioning of an > > image when resizing. > > > > Is there a way to resize thick provisioned images properly, that is, > > maintaining thick provisioning? > > > > Thanks and best regards, > > ================= > > Frank Schilder > > AIT Risø Campus > > Bygning 109, rum S14 > > _______________________________________________ > > ceph-users mailing list -- ceph-users@xxxxxxx > > To unsubscribe send an email to ceph-users-leave@xxxxxxx > > > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |