1 |
On Fri, May 22, 2020 at 2:08 PM antlists <antlists@××××××××××××.uk> wrote: |
2 |
> |
3 |
> So what you could do is allocate one zone of CMR to every four or five |
4 |
> zones of SMR and just reshingle each SMR as the CMR filled up. The |
5 |
> important point is that zones can switch from CMR cache to SMR filling |
6 |
> up, to full SMR zones decaying as they are re-written. |
7 |
|
8 |
I get how this will provide more flexibility. However, there is a big |
9 |
problem here. Unless you are using TRIM you have no idea what space |
10 |
is in use vs free. Once a block has been written to once, it needs to |
11 |
be forever treated as occupied. |
12 |
|
13 |
So this cache really is only useful when the drive is brand new. Once |
14 |
it has all been written once you're limited to dedicated CMR regions |
15 |
for cache, because all the SMR areas are shingled. |
16 |
|
17 |
If you are using TRIM then this does give you more flex space, but |
18 |
only if enough overlapping space is unused, and you do need to |
19 |
reshingle to write to that unused space. Depending on the degree of |
20 |
overlap you still have only a fraction of disk available for your |
21 |
cache. |
22 |
|
23 |
> Which is why I'd break it down to maybe 2GB zones. If as the zone fills |
24 |
> it streams, but is then re-organised and re-written properly when time |
25 |
> permits, you've not got too large chunks of metadata. |
26 |
> ... |
27 |
> The problem with drives at the moment is they run out of CMR cache, so |
28 |
> they have to rewrite all those blocks WHILE THE USER IS STILL WRITING. |
29 |
> The point of my idea is that they can repurpose disk as SMR or CMR as |
30 |
> required, so they don't run out of cache at the wrong time ... |
31 |
|
32 |
You still have a limited cache, and if it fills up you hit the performance wall. |
33 |
|
34 |
The question just comes whether it is more efficient to have |
35 |
flex-space that can be PMR or SMR, or having dedicated space that is |
36 |
PMR-only. I think that depends greatly on whether you can assume the |
37 |
use of TRIM and how much free space the drive will have in general. |
38 |
Since PMR is less dense you have to give up a lot of SMR space for any |
39 |
PMR use of that space. |
40 |
|
41 |
A big problem with drive-managed SMR is that it basically has to |
42 |
assume the OS is dumb, which means most writes are in-place with no |
43 |
trims, assuming the drive even supports trim. |
44 |
|
45 |
-- |
46 |
Rich |