Create pool with no_discard_passdown to avoid an unhelpful error message

[ghost]

Hi,
I get a a lot of errors like this, is it something to worry about? Everything's working fine and the pool can be re-mounted after a reboot:

What does it mean?

[ 261.989567] device-mapper: thin: 253:3: reached low water mark for data device: sending event.
[ 262.064918] device-mapper: thin: Data device (dm-2) discard unsupported: Disabling discard passdown.
[ 262.064962] device-mapper: thin: 253:3: growing the data device from 942848 to 951040 blocks
[ 262.118500] device-mapper: thin: Data device (dm-2) discard unsupported: Disabling discard passdown.

Does this mean that a thin volume will never be able to shrink, or will fstrim still work?

[mulkieran]

Thanks for the question. I can't be sure exactly what version you are running but I think I can give you an answer that covers the possibilities.

These two info messages form a pair and indicate that everything is going as it should:

[ 261.989567] device-mapper: thin: 253:3: reached low water mark for data device: sending event.
[ 262.064962] device-mapper: thin: 253:3: growing the data device from 942848 to 951040 blocks

the thinpool detects that it has used up a preset portion of the available space in its data device. It sent an event; stratisd received it and caused the thinpool data device to be expanded. These are important events, which is why they get logged, but that all looks like correct functioning.

The other two messages are really bookkeeping logs by devicemapper, but they also don't indicate that anything is going wrong.

[ 262.064918] device-mapper: thin: Data device (dm-2) discard unsupported: Disabling discard passdown.
[ 262.118500] device-mapper: thin: Data device (dm-2) discard unsupported: Disabling discard passdown.

What these mean is that the device that is used for the thin pool data device does not support discard, so the thinpool is not going to provide any discard information to that device. It doesn't mean that the thinpool device itself is not going to take what advantage it can of any discard information it may have gotten from xfs.

So if you manually use fstrim on a filesystem on a volume the discarded block information should be communicated to the thinpool which should update its data structures to indicate that these discarded blocks are free and these blocks should be able to be reused.

[agrover]

Sounds like to prevent this message being emitted we should explicitly say "no passdown please". (Not too hard, I'm hoping)

[mulkieran]

This will actually be more work than I had originally thought. We will need to alter how we call ThinPoolDev::new and ThinPoolDev::setup in ThinPool::new and ThinPool::setup respectively. Right now, ThinPoolDev::new and ThinPoolDev::setup have a concept of a default table, and the only values in the default table that can be modified are data_block_size and low_water_mark. It is necessary to decide whether to modify devicemapper-rs defaults, so that no_discard_passdown feautre is set, or to modify devicemapper-rs so that the default no_discard_passdown value can be overridden.

[mulkieran]

devicemapper uses the default table concept for all devices except linear/flakey. If the default table concept is adjusted it should be adjusted uniformly for all. Note that flakey is special, it's feature args are not like all the others.

[mulkieran]

The thing that has made life easy so far is that, although the feature args can be read, devicemapper never interprets them. If interpretation is left to a later time, the question still arises of how they should be written.

[mulkieran]

stratis-storage/devicemapper-rs#401 resolves the problem, but is not a good long term solution. See stratis-storage/devicemapper-rs#400 for what ought to be done.