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

[Dale <rdalek1967@gmail.com>]

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

Michael wrote:
> 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.
>

All true.  This was mentioned by Rich I think way back when I started a
thread about this drive constantly bumping.  I feel the heads moving is
what the bump is.  Until then, I had no idea it was a SMR drive.  I'd
never heard of them before. 


>> 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?  :-/
>

And that is exactly how it works.  It is fast at first, what I see
anyway, but once that buffer/cache fills up, leap year.  It slows by
half or more usually.  The more that gets sent its way, the worse it
gets it seems, watching progress from rsync. 


>> 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.
>

I marked the drive itself with a marker that it is a SMR drive.  I'd
never put that thing in a RAID setup or anything like RAID for that
matter.  I really don't want it in a LVM setup either.  It will always
run as a single drive and for nothing that I need to handle heavy writes
most of the time. 


>> 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.


Well, usually my home backup has only small changes.  Most of it is
config files or my emails.  I do add new videos on occasion but they
stream pretty well to new spots.  What made it hard that time tho, I
moved a lot of files around and renamed things, same as moving to the
file system I guess.  That slowed things down a lot.  I only use it
because I only do backups once a week and it is a nice sized drive with
plenty of room for home.  Otherwise, I'd buy a better drive. 

If I had known it was a SMR drive before I bought it, I would have
bought something else even if it cost a little more.  That is one thing
I like about the company I buy from, they sell mostly drives that are
used in server type systems.  When I asked, they said they don't stock
any SMR drives.  They can special order them for a big customer but they
don't stock them.  Plus, they have good deals and stand behind what they
sell too.  ;-) 

Now to figure out what I'm going to get into today. 

Dale

:-)  :-) 

[-- Attachment #2: Type: text/html, Size: 8155 bytes --]