Bug #15050
closeddeleting striped file in cephfs doesn't free up file's space
0%
Description
I've been creating large (16-64 GB) files in an otherwise empty test cephfs (mounted via the kernel client in linux 4.3.3 (CoreOS 899.5.0)). When a file is deleted, it usually takes 5-10 seconds for the file's space to be reclaimed (df still shows the space used during this period) - but eventually df shows the FS has no space used. However, if I create a directory and change the striping to non-default (ceph.dir.layout="stripe_unit=1048576 stripe_count=4 object_size=8388608 pool=cephfs_data"), then create & delete files, that space is never fully reclaimed.
For example, I've created a 64 GB striped file (confirmed with getfattr to match the above directory layout), then deleted it. I see some space (maybe as much as 16 GB) reclaimed, but the rest stays in limbo - even after a couple days pass. There are no cache pools here; just a single MDS, single MON, and 3x nodes with 3x OSDs each. Both data and metadata pools have size=2, and 128 and 64 PGs respectively.
After doing this several times, I have a filesystem where du claims 270k are in use but df claims 394 GB are used (and rados confirms about 200 GB of objects in my cephfs_data pool).
Am I doing something wrong here? Is there any way to find orphaned FS objects, or a cron job I'm omitting to automatically purge stuff like this? Or is this a bug?