>>>>> Florian-Ewald Müller <florian-ewald.mueller@xxxxxxxxxxxxxxxx> writes: Florian-Ewald, > Now my experiments show that, at least, dm-cache doesn't complain nor > rejects those smaller discards than its discard_granularity, but > possibly turning them into noop (?). Correct. Anything smaller than (an aligned) multiple of the discard granularity will effectively be ignored. In practice this means that your device should allocate things in aligned units of the underlying device's discard granularity. > May be that the needed functionality of accumulating small discards to > a big one covering its own granularity (similar to SSDs block erasure) > should be done at that driver level. Do you allocate blocks in a predictable pattern between your nodes? For MD RAID0, for instance, we issue many small discard requests. But for I/Os that are bigger than the stripe width we'll wrap around and do merging so that for instance blocks 0, n, 2*n, 3*n, etc. become part of the same discard request sent to the device. If you want discards smaller than the underlying granularity to have an effect then I'm afraid the burden is on you to maintain a bitmap of each granularity sized region. And then issue a deferred discard when all blocks inside that region have been discarded by the application or filesystem above. If you want to pursue partial block tracking it would be good to come up with a common block layer infrastructure for it. dm-thin could benefit from it as well... -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
