Re: [gentoo-user] Seagate hard drives with dual actuators.

[Michael <confabulate@kintzios.com>]

[-- Attachment #1: Type: text/plain, Size: 3584 bytes --]

On Friday 15 November 2024 11:59:34 GMT Dale wrote:
> Michael wrote:
> > On Friday 15 November 2024 05:53:53 GMT Dale wrote:
> >> The thing about my data, it's mostly large video files.  If I were
> >> storing documents or something, then SSD or something would be a good
> >> option.  Plus, I mostly write once, then it either sits there a while or
> >> gets read on occasion.
> > 
> > For a write once - read often use case, the SMR drives are a good
> > solution.
> > They were designed for this purpose.  Because of their shingled layers
> > they
> > provide higher storage density than comparable CMR drives.
> 
> True but I don't like when I'm told a write is done, it kinda isn't.  I
> recall a while back I reorganized some stuff, mostly renamed directories
> but also moved some files.  Some were Youtube videos.  It took about 30
> minutes to update the data on the SMR backup drive.  The part I see
> anyway.

Right there is your problem, "... SMR backup drive".  SMRs are best suited to 
sequential writes.  With repeat random writes they go into a read-modify-write 
cycle and slow down.

Consequently, they are well suited to storage of media files, archiving data 
long term and such write-once read-often applications.  They are not suited to 
heavy transactional loads and frequently overwritten data.


> It sat there for a hour at least doing that bumpy thing before
> it finally finished.  I realize if I just turn the drive off, the data
> is still there.  Still, I don't like it appearing to be done when it
> really is still working on it.

SMR drives have to read a whole band of shingled tracks, modify the small 
region where the data has changed and then write the whole band of tracks back 
on the disk in one go.  The onboard cache on drive managed SMRs (DM-SMR) is 
meant to hide this from the OS by queuing up writes before writing them on the 
disk in a sequential stream, but if you keep hammering it with many random 
writes you will soon exhaust the onboard cache and performance then becomes 
glacial.

Host managed SMRs (HM-SMR) require the OS and FS to be aware of the need for 
sequential writes and manage submitted data sympathetically to this limitation 
of the SMR drive, by queuing up random writes in batches and submitting these 
as a sequential stream.

I understand the ext4-lazy option and some patches on btrfs have improved 
performance of these filesystems on SMR drivers, but perhaps f2fs will perform 
better?  :-/


> Another thing, I may switch to RAID one
> of these days.  If I do, that drive isn't a good option. 

Ugh!  RAID striping will combine shingled bands across drives.  A random write 
on one drive will cause other drives to read-modify-write bands.  Whatever 
speed benefit is meant to be derived from striping will be reversed.  On a NAS 
application, where many users could be accessing the storage simultaneously 
trying to save their interwebs downloads, etc., the SMR performance will nose 
dive.


> When I update my backups, I start the one I do with my NAS setup first. 
> Then I start the home directory backup with the SMR drive.  I then
> backup everything else I backup on other drives.  I do that so that I
> can leave the SMR drive at least powered on while it does it's bumpy
> thing and I do other backups.  Quite often, the SMR drive is the last
> one I put back in the safe.  That bumpy thing can take quite a while at
> times. 

Instead of using the SMR for your /home fs backup, you would do better if you 
repurposed it for media files and document backups which do not change as 
frequently.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]