1 |
On Tue, Jun 16, 2020, at 7:25 AM, Rich Freeman wrote: |
2 |
> On Tue, Jun 16, 2020 at 7:36 AM Michael <confabulate@××××××××.com> wrote: |
3 |
> > |
4 |
> > Just to add my 2c's before you throw that SMR away, the use case for these |
5 |
> > drives is to act as disk archives, rather than regular backups. You write |
6 |
> > data you want to keep, once. |
7 |
> |
8 |
> If your write pattern is more like a tape SMR should be ok in theory. |
9 |
> For example, if you wrote to a raw partition using tar (without a |
10 |
> filesystem) I suspect most SMR implementations (including |
11 |
> drive-managed) would work tolerably (a host-managed implementation |
12 |
> would perform identically to CMR). Once you toss in a filesystem then |
13 |
> there is no guarantee that the writes will end up being sequential. |
14 |
> |
15 |
> And of course the problem with these latest hidden SMR drives is that |
16 |
> they generally don't support TRIM, so even repeated sequential writes |
17 |
> can be a problem because the drive doesn't realize that after you send |
18 |
> block 1 you're going to send blocks 2-100k all sequentially. If it |
19 |
> knew that then it would just start overwriting in place obliterating |
20 |
> later tracks, since they're just going to be written next anyway. |
21 |
> Instead this drive is going to cache every write until it can |
22 |
> consolidate them, which isn't terrible but it still turns every seek |
23 |
> into three (write buffer, read buffer, write permanent - plus updating |
24 |
> metadata). If they weren't being sneaky they could have made it |
25 |
> drive-managed WITH TRIM so that it worked more like an SSD where you |
26 |
> get the best performance if the OS uses TRIM, but it can fall back if |
27 |
> you don't. Sequential writes on trimmed areas for SMR should perform |
28 |
> identically to writes on CMR drives. |
29 |
> |
30 |
|
31 |
So if I'm understanding properly most drive firmware won't let you |
32 |
operate the device in an append-only mode? If any do I suspect |
33 |
NILFS (https://en.wikipedia.org/wiki/NILFS) may be a good choice: |
34 |
|
35 |
"NILFS is a log-structured filesystem, in that the storage medium is treated |
36 |
like a circular buffer and new blocks are always written to the end. [...]" |
37 |
|
38 |
Realistically I don't know how maintained the filesystem is, and it may |
39 |
still enforce a hot and warm/cold data separation as a practical concern. |
40 |
As-is my intended use for these very large drives was not going to be for |
41 |
hot files anyway; spinning media is too slow. They were going to be running |
42 |
a snapshottable filesystem and would host my backups. |
43 |
|
44 |
But if I'm reading it right these drives just suck across the board? I'm |
45 |
confused. It's like they'd be good at one thing but then they tried to |
46 |
lie behind the scenes and ended up making the drives good at nothing. |