Rich Freeman wrote: > On Thu, Jan 2, 2020 at 1:41 PM Dale <rdalek1...@gmail.com> wrote: >> Rich Freeman wrote: >>> Out of curiosity, what model drive is it? Is it by chance an SMR / >>> archive drive? >> Device Model: ST8000AS0003-2HH188 >> >> I recall reading about SMR but can't recall the details of what it is. >> As far as I know, this is just a basic 8TB drive. > This is an SMR drive. You should DEFINITELY read up on what they are. > > For reads they're completely normal. For sequential writes to unused > space they're completely normal. For random writes or overwrites they > are significantly different from traditional hard drives. > > They work a bit like an SSD in the sense that blocks are arranged into > larger erase regions. Within a region blocks can only be written > sequentially. If you want to overwrite one block in the middle of a > region, the drive will read the entire region into RAM, then write the > entire region sequentially with the overwritten block to a new spot on > the disk. This is just like in an SSD where if try to overwrite a > block in a region with any unTRIMmed blocks the drive must read the > entire region, erase the region, and write the modified region. > > Except that in an SSD those extra reads/writes operate with SSD access > times. With an SMR drive those extra reads/writes operate with hard > drive latencies, so they're MUCH more costly. > > For backup use they're usually fine, IF you're writing in a sequential > file format that is appended to. If you're using rsync to do your > backups then that isn't what you're doing and you're probably paying a > heavy penalty. If you were doing incremental backups using > tar/duplicity/whatever then you'd probably be fine. > > Some filesystems might be optimized for these drives to reduce the > amount of overwriting in place. I haven't looked into it. I'd expect > a log-based filesystem to work fairly well, though those can have high > levels of fragmentation which is better suited for SSD than SMR. > > These drives all have fairly active firmware that manages this special > overwrite process so that they can be used with operating systems that > are naive to how they work. I wouldn't be surprised if this is what > is causing the drive to be active after you unmount it. In theory it > should be harmless to power it off. However, leaving it powered on > probably will improve its performance as it can take care of any > garbage collection before the next time you use it. If whatever > journal it is using to speed things up gets full then you'll feel the > full brunt of any write penalties until it is flushed. > > You might want to seriously consider changing to a backup format that > just creates big tail-appended files containing incremental changes. > Something like rsync that just outputs bazillions of little files is > going to create lots of random writes when things change, vs > consolidating all those changes into one file that just grows at the > end. Treat them the way you would a tape (which is what tar was > designed for). > > Nothing wrong with SMR drives per se - they can potentially be cheaper > especially for backup (using an appropriate file format), and are just > as fast for reading so they're also great for infrequently changing > bulky data. However, random writes are very costly and you should be > aware of that going in... >
I had no idea this was that type of drive. I wonder if any of my other drives are this type as well. If it matters, I use ext4 on my drives, except /boot, but I've thought about using something that is also compatible with windoze, just in case I need to copy some things to someone else's system. Thing is, I'm not real big on those file systems since I lose some info such as permissions and all. Does my using ext4 change this any? Better or worse? Should I change the mounting options for this drive? I've read some people use certain options for SSD and they are needed. This is the options being used according to mount: /dev/sdj1 on /run/media/dale/8tb-backup type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2) That I guess is the default way KDE/udisks/etc does it. One other question, what should I look for to avoid these types of drives? I'll go back and look but I don't recall it saying anything about this. I'm also trying to figure out if this is a good thing or not. Thanks much for the info. I'll read this one again shortly. Lot of info to absorb. Dale :-) :-)
