- ceph-users - lists.ceph.io

Re: How to copy an OSD from one failing disk to another one
by Janne Johansson 08 Dec '20

08 Dec '20

"ceph osd set norebalance" "ceph osd set nobackfill" Add new OSD, set osd weight to 0 on old OSD unset the norebalance and nobackfill options, and the cluster will do it all for you. Den tis 8 dec. 2020 kl 13:13 skrev huxiaoyu(a)horebdata.cn < huxiaoyu(a)horebdata.cn>: > Hi, dear cephers, > > On one ceph i have a failing disk, whose SMART information signals an > impending failure but still availble for reads and writes. I am setting up > a new disk on the same node to replace it. > What is the best procedure to migrate data (or COPY ) from the failing OSD > to the new one? > > Is there any stardard method to copy the OSD from one to another? > > best regards, > > samuel > > > > huxiaoyu(a)horebdata.cn > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io > -- May the most significant bit of your life be positive.

2 1

CfP Software Defined Storage devroom
by Jan Fajerski 08 Dec '20

08 Dec '20

FOSDEM is a free software event that offers open source communities a place to meet, share ideas and collaborate. It is well known for being highly developer-oriented and in the past brought together 8000+ participants from all over the world. It's home is in the city of Brussels (Belgium). FOSDEM 2021 will take place as an online event during the weekend of February 6./7. 2021. More details about the event can be found at http://fosdem.org/ ** Call For Participation The Software Defined Storage devroom will go into it's fifth round for talks around Open Source Software Defined Storage projects, management tools and real world deployments. Presentation topics could include but are not limited too: - Your work on a SDS project like Ceph, Gluster, OpenEBS, CORTX or Longhorn - Your work on or with SDS related projects like OpenStack SWIFT or Container Storage Interface - Management tools for SDS deployments - Monitoring tools for SDS clusters ** Important dates: - Dec 27th 2020: submission deadline for talk proposals - Dec 31st 2020: announcement of the final schedule - Feb 6th 2021: Software Defined Storage dev room Talk proposals will be reviewed by a steering committee: - Niels de Vos (OpenShift Container Storage Developer - Red Hat) - Jan Fajerski (Ceph Developer - SUSE) - TBD Use the FOSDEM 'pentabarf' tool to submit your proposal: https://penta.fosdem.org/submission/FOSDEM21 - If necessary, create a Pentabarf account and activate it. Please reuse your account from previous years if you have already created it. https://penta.fosdem.org/user/new_account/FOSDEM21 - In the "Person" section, provide First name, Last name (in the "General" tab), Email (in the "Contact" tab) and Bio ("Abstract" field in the "Description" tab). - Submit a proposal by clicking on "Create event". - If you plan to register your proposal in several tracks to increase your chances, don't! Register your talk once, in the most accurate track. - Presentations have to be pre-recorded before the event and will be streamed on the event weekend. - Important! Select the "Software Defined Storage devroom" track (on the "General" tab). - Provide the title of your talk ("Event title" in the "General" tab). - Provide a description of the subject of the talk and the intended audience (in the "Abstract" field of the "Description" tab) - Provide a rough outline of the talk or goals of the session (a short list of bullet points covering topics that will be discussed) in the "Full description" field in the "Description" tab - Provide an expected length of your talk in the "Duration" field. We suggest a length between 15 and 45 minutes. ** For accepted talks Once your proposal is accepted we will assign you a volunteer deputy who will help you to produce the talk recording. The volunteer will also try to ensure the recording is of good quality, help with uploading it to the system, broadcasting it during the event and moderate the Q&A session after the broadcast. Please note that as a presenter you're expected to be available online during and especially after the broadcast of you talk. The schedule will be available under https://fosdem.org/2021/schedule/track/software_defined_storage/ Hope to hear from you soon! And please forward this announcement. If you have any further questions, please write to the mailing list at storage-devroom(a)lists.fosdem.org and we will try to answer as soon as possible. Thanks!

1 0

MDS lost, Filesystem degraded and wont mount
by Anton Aleksandrov 08 Dec '20

08 Dec '20

Hello community, we are on ceph 13.2.8 - today something happenned with one MDS and cephs status tells, that filesystem is degraded. It won't mount either. I have take server with MDS, that was not working down. There are 2 more MDS servers, but they stay in "rejoin" state. Also only 1 is shown in "services", even though there are 2. Both running MDS servers have these lines in their logs: heartbeat_map is_healthy 'MDSRank' had timed out after 15 mds.beacon.mds2 Skipping beacon heartbeat to monitors (last acked 28.8979s ago); MDS internal heartbeat is not healthy! On one of MDS nodes I enabled more detailed debug, so I am getting there also: mds.beacon.mds3 Sending beacon up:standby seq 178 mds.beacon.mds3 received beacon reply up:standby seq 178 rtt 0.000999968 Makes no sense and too much stress in my head... Anyone could help please? Anton.

4 14

Garbage Collection on Luminous
by Priya Sehgal 07 Dec '20

07 Dec '20

Hi, I have a production cluster and it is experiencing lot of DELETES since many months. However, with the default gc configs - I did not see the cluster space utilization going down. Moreover, the gc list has more than 4 million objects. I tried increasing the gc configs on 4 rados gateways and fired manual gc using the command: *sudo radosgw-admin gc process* The changed GC configs are as follows: rgw gc max objs = 100 rgw gc obj min wait = 3600 rgw gc processor max time = 900 rgw gc processor period = 3600 rgw gc max concurrent io = 20 rgw gc max trim chunk = 64 *Questions* 1. Since the cluster is active cluster and having both PUT and DELETE requests - I am unable to determine whether manual GC is indeed helping. I did see an increase in free space one day - but from the past few days I do not see any increase in free space. How do I determine whether GC is really running? *sudo radosgw-admin gc list | grep oid | wc -l * This command the list is always increasing and I do see very old objects when I grep for oid. 2. Does GC have some problems running automatically on Luminous? It is enabled. 3. Are the above configs fine or can they be made more aggressive? 4. Is there a faster way to claim space which is pending GC without impacting much performance? Thanks and Regards, Priya -- *-----------------------------------------------------------------------------------------* *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.***** **** *Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organization. Any information on shares, debentures or similar instruments, recommended product pricing, valuations and the like are for information purposes only. It is not meant to be an instruction or recommendation, as the case may be, to buy or to sell securities, products, services nor an offer to buy or sell securities, products or services unless specifically stated to be so on behalf of the Flipkart group. Employees of the Flipkart group of companies are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to organizational policy and outside the scope of the employment of the individual concerned. The organization will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising.***** **** *Our organization accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information *provided,* unless that information is subsequently confirmed in writing. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* _-----------------------------------------------------------------------------------------_

2 1

Re: guest fstrim not showing free space
by John Petrini 07 Dec '20

07 Dec '20

What driver did you use to mount the volumes? I believe only virtio-scsi supports fstrim commands.

2 2

Re: guest fstrim not showing free space
by Nathan Fish 07 Dec '20

07 Dec '20

Is the VM's / ext4? On Sun., Dec. 6, 2020, 12:57 p.m. Marc Roos, <M.Roos(a)f1-outsourcing.eu> wrote: > > > I have a 74GB vm with 34466MB free space. But when I do fstrim / 'rbd > du' shows still 60GB used. > When I fill the 34GB of space with an image, delete it and do again the > fstrim 'rbd du' still shows 59GB used. > > Is this normal? Or should I be able to get it to ~30GB used? > > > > > > > > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io >

2 2

Ceph in FIPS Validated Environment
by Van Alstyne, Kenneth 07 Dec '20

07 Dec '20

All: I recently was tasked with building and implementing Ceph in an environment where FIPS cryptography is strictly enforced. As such, I ran into several issues regarding Ceph's use of low-level cryptographic functions since those are strictly forbidden when OpenSSL is in FIPS mode. The obvious solution is to migrate away from the low level crypto functions and over to OpenSSL's EVP API, which I wrongly assumed would be a huge undertaking. As it turns out, low level crypto functions are only used in a handful of places and the work to migrate away has already been completed in the following PRs: https://github.com/ceph/ceph/pull/23260 https://github.com/ceph/ceph/pull/32675 The latter looks like will be merged in for the Pacific release, but the former appears to have been abandoned. The perception is that these pulls are only related to performance improvements, but they also solve the corner case of running Ceph in a FIPS-enforced environment. Anecdotally, I rebased the two pulls on the latest stable Octopus release, 15.2.7, and have a cluster up and running with no issues as far as I can tell in a FIPS-enforced environment. Are there any thoughts about reopening PR#23260 and updating both PRs to notate that they also resolve FIPS compatibility issues? Thanks, -- Kenneth Van Alstyne Systems Architect M: 804.240.2327 14291 Park Meadow Drive, Chantilly, VA 20151 perspecta

1 0

Re: set rbd metadata 'conf_rbd_qos_bps_limit', make 'mkfs.xfs /dev/nbdX ' blocked
by 912273695＠qq.com 07 Dec '20

07 Dec '20

Hi，Jason： As discussed last time，After setting conf_rbd_qos_bps_limit, the speed of discard is also limited， which can make operation such as mkfs.xfs very slow, though we can add -K option to solve this problem, but we can't make sure that other operation or application never call discard interface, so if the discard operation can be not limited by conf_rbd_qos_bps_limit option, and if so, is there any other risk? Thanks. Beset Regards， LiuGangbiao

1 0

dashboard 500 internal error when listing buckets
by levin ng 07 Dec '20

07 Dec '20

Hi all, I just have done 15.2.7 installation with having 3 mon , 4 osd and 3 rgw, however after enabling rgw dashboard, the buckets page popup 500 internal error, but users and daemons are listed fine in the dashboard, radosgw-admin can list out everything without problem as well. I've tired to turn on rgw and mgr debug log the logs just shown as below, I would appreciate if you have any idea to fix this problem. Thank you! mgr log: debug 2020-12-07T07:48:32.761+0000 7f057a17d700 0 [dashboard ERROR request] [172.25.88.12:44024] [GET] [500] [0.050s] [admin] [513.0B] /api/rgw/bucket/test91 debug 2020-12-07T07:48:32.761+0000 7f057a17d700 0 [dashboard ERROR request] [b'{"status": "500 Internal Server Error", "detail": "The server encountered an unexpected condition which prevented it from fulfilling the request.", "request_id": "0b4cfe92-c25d-474f-ad51-05d441c260df"} rgw log: debug 2020-12-07T09:09:20.725+0000 7f2d16bdf700 1 ====== starting new request req=0x7f2d76d913a0 ===== debug 2020-12-07T09:09:20.725+0000 7f2d16bdf700 2 req 4313 0s initializing for trans_id = tx0000000000000000010d9-005fcdf140-40bb4-cast debug 2020-12-07T09:09:20.725+0000 7f2d16bdf700 2 req 4313 0s getting op 0 debug 2020-12-07T09:09:20.725+0000 7f2d16bdf700 2 req 4313 0s s3:list_bucket verifying requester debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket normalizing buckets and tenants debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket init permissions debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket recalculating target debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket reading permissions debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket init op debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket verifying op mask debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket verifying op permissions debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 req 4313 0.030002579s s3:list_bucket Searching permissions for identity=rgw::auth::SysReqApplier -> rgw::auth::RemoteApplier(acct_user=test91-tsa, acct_name=test91-tsa, perm_mask=15, is_admin=0) mask=49 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Searching permissions for uid=test91-tsa debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Found permission: 15 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Searching permissions for uid=test91-tsa$test91-tsa debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Permissions for user not found debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Searching permissions for group=1 mask=49 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Permissions for group not found debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Searching permissions for group=2 mask=49 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 Permissions for group not found debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 5 req 4313 0.030002579s s3:list_bucket -- Getting permissions done for identity=rgw::auth::SysReqApplier -> rgw::auth::RemoteApplier(acct_user=test91-tsa, acct_name=test91-tsa, perm_mask=15, is_admin=0), owner=test91-tsa, perm=1 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket verifying op params debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket pre-executing debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 2 req 4313 0.030002579s s3:list_bucket executing debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.20:6800/2627145462,v1:172.25.88.20:6801/2627145462] -- osd_op(unknown.0.0:36867 15.5 15:a0395ab0:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.0:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b1258ffb80 con 0x55b125517800 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.19:6800/4042281875,v1:172.25.88.19:6801/4042281875] -- osd_op(unknown.0.0:36868 15.4 15:2069ca14:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.1:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b126b0c780 con 0x55b125516400 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.17:6800/1165805227,v1:172.25.88.17:6801/1165805227] -- osd_op(unknown.0.0:36869 15.2 15:40c91296:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.2:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b129b04f00 con 0x55b1246e4800 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.17:6800/1165805227,v1:172.25.88.17:6801/1165805227] -- osd_op(unknown.0.0:36870 15.2 15:58086687:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.3:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b129b05680 con 0x55b1246e4800 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.17:6800/1165805227,v1:172.25.88.17:6801/1165805227] -- osd_op(unknown.0.0:36871 15.7 15:e9aebc19:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.4:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b127f5f180 con 0x55b1246e4800 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.17:6800/1165805227,v1:172.25.88.17:6801/1165805227] -- osd_op(unknown.0.0:36872 15.7 15:e0023539:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.5:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b1279f6f00 con 0x55b1246e4800 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.19:6800/4042281875,v1:172.25.88.19:6801/4042281875] -- osd_op(unknown.0.0:36873 15.1 15:9600557f:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.6:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b12b8ec280 con 0x55b125516400 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.19:6800/4042281875,v1:172.25.88.19:6801/4042281875] -- osd_op(unknown.0.0:36874 15.4 15:2984dfaf:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.7:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b12a320500 con 0x55b125516400 debug 2020-12-07T09:09:20.755+0000 7f2d16bdf700 1 -- 172.25.88.14:0/3384359887 --> [v2: 172.25.88.20:6800/2627145462,v1:172.25.88.20:6801/2627145462] -- osd_op(unknown.0.0:36875 15.5 15:b8046cce:::.dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.8:head [call rgw.bucket_list in=47b] snapc 0=[] ondisk+read+known_if_redirected e1209) v8 -- 0x55b129b20280 con 0x55b125517800 debug 2020-12-07T09:09:20.756+0000 7f2d65652700 1 -- 172.25.88.14:0/3384359887 <== osd.0 v2:172.25.88.17:6800/1165805227 7141 ==== osd_op_reply(36872 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.5 [call out=1507b] v0'0 uv369 ondisk = 0) v8 ==== 196+0+1507 (crc 0 0 0) 0x55b12b719b00 con 0x55b1246e4800 debug 2020-12-07T09:09:20.756+0000 7f2d65652700 1 -- 172.25.88.14:0/3384359887 <== osd.0 v2:172.25.88.17:6800/1165805227 7142 ==== osd_op_reply(36870 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.3 [call out=2033b] v0'0 uv293 ondisk = 0) v8 ==== 196+0+2033 (crc 0 0 0) 0x55b12b719b00 con 0x55b1246e4800 debug 2020-12-07T09:09:20.756+0000 7f2d65652700 1 -- 172.25.88.14:0/3384359887 <== osd.0 v2:172.25.88.17:6800/1165805227 7143 ==== osd_op_reply(36876 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.9 [call out=1626b] v0'0 uv371 ondisk = 0) v8 ==== 196+0+1626 (crc 0 0 0) 0x55b12b719b00 con 0x55b1246e4800 debug 2020-12-07T09:09:20.756+0000 7f2d65652700 1 -- 172.25.88.14:0/3384359887 <== osd.3 v2:172.25.88.20:6800/2627145462 6963 ==== osd_op_reply(36867 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.0 [call out=642b] v0'0 uv211 ondisk = 0) v8 ==== 196+0+642 (crc 0 0 0) 0x55b12b719b00 con 0x55b125517800 debug 2020-12-07T09:09:20.756+0000 7f2d65652700 1 -- 172.25.88.14:0/3384359887 <== osd.3 v2:172.25.88.20:6800/2627145462 6964 ==== osd_op_reply(36875 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.8 [call out=1610b] v0'0 uv213 ondisk = 0) v8 ==== 196+0+1610 (crc 0 0 0) 0x55b12b719b00 con 0x55b125517800 debug 2020-12-07T09:09:20.756+0000 7f2d64650700 1 -- 172.25.88.14:0/3384359887 <== osd.2 v2:172.25.88.19:6800/4042281875 10713 ==== osd_op_reply(36868 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.1 [call out=2931b] v0'0 uv199 ondisk = 0) v8 ==== 196+0+2931 (crc 0 0 0) 0x55b12b462fc0 con 0x55b125516400 debug 2020-12-07T09:09:20.757+0000 7f2d64650700 1 -- 172.25.88.14:0/3384359887 <== osd.2 v2:172.25.88.19:6800/4042281875 10714 ==== osd_op_reply(36873 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.6 [call out=149b] v0'0 uv213 ondisk = 0) v8 ==== 196+0+149 (crc 0 0 0) 0x55b12b462fc0 con 0x55b125516400 debug 2020-12-07T09:09:20.757+0000 7f2d64650700 1 -- 172.25.88.14:0/3384359887 <== osd.2 v2:172.25.88.19:6800/4042281875 10715 ==== osd_op_reply(36874 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.7 [call out=110b] v0'0 uv169 ondisk = 0) v8 ==== 196+0+110 (crc 0 0 0) 0x55b12b462fc0 con 0x55b125516400 debug 2020-12-07T09:09:20.757+0000 7f2d64650700 1 -- 172.25.88.14:0/3384359887 <== osd.2 v2:172.25.88.19:6800/4042281875 10716 ==== osd_op_reply(36877 .dir.4f3ad19b-c138-4c21-a860-df0df8841e27.179340.6.10 [call out=1052b] v0'0 uv215 ondisk = 0) v8 ==== 197+0+1052 (crc 0 0 0) 0x55b12b462fc0 con 0x55b125516400 debug 2020-12-07T09:09:20.757+0000 7f2d16bdf700 2 req 4313 0.032002751s s3:list_bucket completing debug 2020-12-07T09:09:20.757+0000 7f2d06bbf700 2 req 4313 0.032002751s s3:list_bucket op status=0 debug 2020-12-07T09:09:20.757+0000 7f2d06bbf700 2 req 4313 0.032002751s s3:list_bucket http status=200 debug 2020-12-07T09:09:20.757+0000 7f2d06bbf700 1 ====== req done req=0x7f2d76d913a0 op status=0 http_status=200 latency=0.032002751s ======

1 0

guest fstrim not showing free space
by Marc Roos 06 Dec '20

06 Dec '20

I have a 74GB vm with 34466MB free space. But when I do fstrim / 'rbd du' shows still 60GB used. When I fill the 34GB of space with an image, delete it and do again the fstrim 'rbd du' still shows 59GB used. Is this normal? Or should I be able to get it to ~30GB used?

2 2