stratis-storage/stratis-cli

Usage reported by stratis filesystem list does not match usage reported by df

Closed this issue · 2 comments

see https://bugzilla.redhat.com/show_bug.cgi?id=1655154

Description of problem:  Two tools on the system give different answers.  See the following:

[root@TheOcholet cool_data]# stratis filesystem list
Pool Name       Name                     Used      Created            Device                                               
AverageJoes     cash_money_data          546 MiB   Nov 30 2018 10:40  /dev/stratis/AverageJoes/cash_money_data             
AverageJoes     lockdown_snapshot        546 MiB   Nov 30 2018 10:54  /dev/stratis/AverageJoes/lockdown_snapshot           
BoldMoveCotton  lets_see_if_it_pays_off  9.95 GiB  Nov 30 2018 10:39  /dev/stratis/BoldMoveCotton/lets_see_if_it_pays_off  

The file system managed by stratis at the mount point 'cash_money_data' is unused, only 546M are consumed.  However 'df' reports teh following:

[root@TheOcholet cool_data]# df -h | grep -i stratis
/dev/mapper/stratis-1-e43c38cb5eee425fb0a0d856bddd24ac-thin-fs-fdb04ce31c584999846bf64d463c1b6a  1.0T  7.3G 1017G   1% /mnt/cool_data
/dev/mapper/stratis-1-89f2f4fe77f24723ae690c34dee44c5f-thin-fs-8730b56202e14866ab9451399900b37b  1.0T  7.2G 1017G   1% /mnt/cash_money_data

So, the filesystem size, usage, etc are all reported inaccurately.  This will likely cause confusion and support cases.

Note that stratis does not report the filesystem size inaccurately. It doen't report the filesystem size at all, so it can't report it either accurately or inaccurately.

It does report a value called "Used" that differs from the value that df calls "Used". But it's not clear that either value is inaccurate. They mean different things in the context of their different tools.

I'm not sure what "etc" is intended to mean in this context.

We should more thoroughly document the meaning of the columns in our man pages. I'll open a separate issue for that, since it is a bit more general than this bug: #225.

Closing this in favor of #225.