Wondering if updating DB directly would have any effect on the calculations
- It will probably happen that this pool "detail" (overprovisioning factor)
is not taken into consideration at all, even if the DB record is there.
Try adding a new row to the storage_pool_details table - i.e.
INSERT INTO `cloud`.`storage_pool_details` (`id`, `pool_id`, `name`,
`value`, `display`) VALUES ('9', '2', 'storage.overprovisioning.factor',
'2', '1');
Obviously, change your pool_id and the id as needed in that table.
Andrija
On Tue, Sep 17, 2019, 10:46 Piotr Pisz <[email protected]> wrote:
> We've set the overprovisioning to 2, and clearly doesn't work on
> SharedMountPoint :(
>
>
>
> “Unable to update storage pool with id 19. Overprovision not supported
> for SharedMountPoint”
>
>
>
> Piotr
>
>
>
>
>
> *From:* Andrija Panic <[email protected]>
> *Sent:* Tuesday, September 17, 2019 9:15 AM
> *To:* users <[email protected]>; Piotr Pisz <[email protected]>
> *Subject:* Re: disk total vs disk allocated
>
>
>
> So, that sounds OK I guess.
>
>
>
> Can you try setting the overprovisioning on that Primary Storage
> specifically? I can't really say if storage overprovisioning is supported
> for shared mount point (it is supported for NFS, local and probably RBD) -
> though that is only the code logic.
>
>
>
> Andrija
>
>
>
> On Tue, Sep 17, 2019, 08:50 Piotr Pisz <[email protected]> wrote:
>
> Thank you everyone, I didn't really realize that my friends made so many
> thin disks.
> The storage.alloction.overprovisioning.factor parameter could be useful,
> what is the point of using thin disks if the capacity of the pool cannot be
> exceeded?
>
> MariaDB [cloud]> select round(size/1024/1024/1024, 2) as "size [GB]",
> state from volumes where pool_id = 19 and removed is NULL;
> +-----------+-------+
> | size [GB] | state |
> +-----------+-------+
> | 2048.00 | Ready |
> | 0.36 | Ready |
> | 1024.00 | Ready |
> | 1024.00 | Ready |
> | 1024.00 | Ready |
> | 1024.00 | Ready |
> | 1024.00 | Ready |
> | 1024.00 | Ready |
> | 1024.00 | Ready |
> | 30.00 | Ready |
> | 100.00 | Ready |
> | 50.00 | Ready |
> | 60.00 | Ready |
> | 50.00 | Ready |
> | 50.00 | Ready |
> | 50.00 | Ready |
> | 100.00 | Ready |
> | 50.00 | Ready |
> | 100.00 | Ready |
> | 500.00 | Ready |
> | 250.00 | Ready |
> | 250.00 | Ready |
> | 250.00 | Ready |
> | 250.00 | Ready |
> | 250.00 | Ready |
> | 40.00 | Ready |
> | 100.00 | Ready |
> +-----------+-------+
> 27 rows in set (0.001 sec)
>
> Regards,
> Piotr
>
>
> -----Original Message-----
> From: Andrija Panic <[email protected]>
> Sent: Tuesday, September 17, 2019 8:10 AM
> To: users <[email protected]>; Piotr Pisz <[email protected]>
> Subject: Re: disk total vs disk allocated
>
> Wow.. . That's the community spirit - 3 replies in 8min from the original
> email!
>
> On Tue, Sep 17, 2019, 08:07 Andrija Panic <[email protected]> wrote:
>
> > Hi Piotr,
> >
> > Allocated should be the sum of all disks virtual size from the DB,
> > "volumes" table.
> >
> > Can you do select sum "size" from that table, where pool_id=xxx and
> > removed is NULL (on my mobile, can't remember the name of the column
> > in the table, probability just "size").
> >
> > More importantly, I'm wondering how is this working for you? Did you
> > have time to test that setup "properly"? Any feedbacks?
> >
> > Best,
> > Andrija
> >
> > On Tue, Sep 17, 2019, 08:00 Piotr Pisz <[email protected]> wrote:
> >
> >> Hi all,
> >>
> >> I have a strange situation, we have a CephFS share mounted as
> >> SharedMountPoint.
> >> CS shows Disk Total as 12T (that's ok), while Disk Allocated shows
> >> like 11.8T (it's not ok, disk is 50% full).
> >> How can We diagnose the cause?
> >>
> >> Regards,
> >> Piotr
> >>
> >>
>
>
