Thread (2 messages) 2 messages, 2 authors, 2016-08-02

Re: [PATCH linux-4.7-rc7] blk_stack_limits() setting discard_granularity

From: Martin K. Petersen <hidden>
Date: 2016-08-02 02:10:51

quoted
quoted
quoted
quoted
Florian-Ewald Müller [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help