1 |
On Mon, Jan 6, 2020 at 8:25 AM Mick <michaelkintzios@×××××.com> wrote: |
2 |
> |
3 |
> If they are used as normal PC drives for regular writing |
4 |
> of data, or with back up commands which use rsync, cp, etc. then the disk will |
5 |
> fail much sooner than expected because of repeated multiple areas being |
6 |
> deleted, before each smaller write. I recall reading about how short the life |
7 |
> of SMR drives was shown to be when used in NAS devices - check google or |
8 |
> youtube if you're interested in the specifics. |
9 |
|
10 |
Can you give a link - I'm not finding anything, and I'm a bit dubious |
11 |
of this claim, because they still are just hard drives. These aren't |
12 |
SSDs and hard drives should not have any kind of erasure limit. |
13 |
|
14 |
Now, an SMR used for random writes is going to be a REALLY busy drive, |
15 |
so I could see the drive being subject to a lot more wear and tear. |
16 |
I'm just not aware of any kind of serious study. And of course any |
17 |
particular model of hard drive can have reliability issues (just look |
18 |
up the various reliability studies). |
19 |
|
20 |
> Personally, I would only use such a drive for 'keepers'. Say, films I intend |
21 |
> to write once and watch many times, ripped music albums, family photos, etc. |
22 |
> For OS files and other temporary backups I would use a normal PC drive. |
23 |
|
24 |
Certainly I would never use an SMR for an OS or /home. Backups should |
25 |
be fine, as long as you're using a sequential backup file format. |
26 |
tar/duplicity should be fine. Dar is probably fine but I'd need to |
27 |
check (I think it just writes the index to the end, so the seeking |
28 |
issues are on reading and not writing). Even zip/etc is going to be |
29 |
fine. What is going to be a problem is anything that just replicates |
30 |
the original data as all the separate files/directories that exist on |
31 |
the original drive, like rsync/rsnapshot/etc. Those formats are of |
32 |
course attractive because the backup is just a replica of the |
33 |
original, but they involve random writes. Most formats that just |
34 |
create a bunch of files named archive-001.foo that need a special |
35 |
command to restore are going to be fine. |
36 |
|
37 |
I personally haven't encountered a need to consider an SMR drive as |
38 |
you can shuck those 12TB Easystore drives for something like $180 on |
39 |
sale, at least in the US. Those are just standard drives (often with |
40 |
red firmware). I couldn't even use them for my multimedia as I'm |
41 |
storing that stuff on lizardfs right now and that breaks everything |
42 |
into chunks. Granted, I don't rewrite it often but unless zfs is |
43 |
SMR-aware it is still going to be writing lots of modest-sized files |
44 |
as the original files get chunked up and distributed across the nodes. |
45 |
On the disk lizardfs data just looks like a browser cache, with |
46 |
everything in numbered files about 60MB in size in my case. The files |
47 |
also appear to turn over a bit during rebalancing. |
48 |
|
49 |
-- |
50 |
Rich |