1 |
On Tue, Jun 16, 2020 at 7:36 AM Michael <confabulate@××××××××.com> wrote: |
2 |
> |
3 |
> Just to add my 2c's before you throw that SMR away, the use case for these |
4 |
> drives is to act as disk archives, rather than regular backups. You write |
5 |
> data you want to keep, once. |
6 |
|
7 |
If your write pattern is more like a tape SMR should be ok in theory. |
8 |
For example, if you wrote to a raw partition using tar (without a |
9 |
filesystem) I suspect most SMR implementations (including |
10 |
drive-managed) would work tolerably (a host-managed implementation |
11 |
would perform identically to CMR). Once you toss in a filesystem then |
12 |
there is no guarantee that the writes will end up being sequential. |
13 |
|
14 |
And of course the problem with these latest hidden SMR drives is that |
15 |
they generally don't support TRIM, so even repeated sequential writes |
16 |
can be a problem because the drive doesn't realize that after you send |
17 |
block 1 you're going to send blocks 2-100k all sequentially. If it |
18 |
knew that then it would just start overwriting in place obliterating |
19 |
later tracks, since they're just going to be written next anyway. |
20 |
Instead this drive is going to cache every write until it can |
21 |
consolidate them, which isn't terrible but it still turns every seek |
22 |
into three (write buffer, read buffer, write permanent - plus updating |
23 |
metadata). If they weren't being sneaky they could have made it |
24 |
drive-managed WITH TRIM so that it worked more like an SSD where you |
25 |
get the best performance if the OS uses TRIM, but it can fall back if |
26 |
you don't. Sequential writes on trimmed areas for SMR should perform |
27 |
identically to writes on CMR drives. |
28 |
|
29 |
|
30 |
-- |
31 |
Rich |