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

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

[Dale]

Howdy,

One of my PVs is about 83% full.  Time to add more space, soon anyway.
I try not to go past 90%.  Anyway, I was looking at hard drives and
noticed something new.  I think I saw one a while back but didn't look
into it at the time.  I'm looking at 18TB drives, right now.  Some new
Seagate drives have dual actuators.  Basically, they have two sets of
heads.  In theory, if circumstances are right, it could read data twice
as fast.  Of course, most of the time that won't be the case but it can
happen often enough to make it get data a little faster.  Even a 25% or
30% increase gives Seagate something to brag about.  Another sales tool.
 Some heavy data users wouldn't mind either.

My question is this.  Given they cost about $20 more, from what I've
found anyway, is it worth it?  Is there a downside to this new set of
heads being added?  I'm thinking a higher failure rate, more risk to
data or something like that.  I think this is a fairly new thing, last
couple years or so maybe.  We all know how some new things don't work out.

Just looking for thoughts and opinions, facts if someone has some.
Failure rate compared to single actuator drives if there is such data.
My searched didn't help me find anything useful.

Thanks.

Dale

:-)  :-)

P. S.  My greens are growing like weeds.  Usually they ready to pick by
now but having to wait for the tree to be cut down and cut up delayed
that.  Should be ready by Christmas, I hope.  Oh, planted oats, clover,
kale and some other extra seeds I had in open area.  I saw a LARGE buck
deer the other night snacking on the oats.  My neighbor would rather see
it in his freezer tho.  o_0

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

[Matt Jolly]

Hi Dale,

> My question is this.  Given they cost about $20 more, from what I've
> found anyway, is it worth it?  Is there a downside to this new set of
> heads being added?  I'm thinking a higher failure rate, more risk to
> data or something like that.  I think this is a fairly new thing, last
> couple years or so maybe.  We all know how some new things don't work out.

At least one vendor has been trying to sell me on these recently,
claiming higher bandwidth and better ability to seek. I have not yet
actually used these.

> Just looking for thoughts and opinions, facts if someone has some.
> Failure rate compared to single actuator drives if there is such data.
> My searched didn't help me find anything useful.

There's no reason to suspect that these are going to be terrible, they
appear to be the next step on the Seagate roadmap before HAMR drives
hit the market in the coming years.

I haven't seen much on the reliability side of things, however I 
wouldn't be too concerned, assuming that there's proper backup in place 
- Any other drive (including SSDs) could "just die" for a multitude of
reasons.

> P. S.  My greens are growing like weeds.  Usually they ready to pick by
> now but having to wait for the tree to be cut down and cut up delayed
> that.  Should be ready by Christmas, I hope.  Oh, planted oats, clover,
> kale and some other extra seeds I had in open area.  I saw a LARGE buck
> deer the other night snacking on the oats.  My neighbor would rather see
> it in his freezer tho.  o_0

Hopefully there's some left for you!

Cheers,

Matt

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

[Wols Lists]

On 13/11/2024 23:10, Dale wrote:
> My question is this.  Given they cost about $20 more, from what I've
> found anyway, is it worth it?  Is there a downside to this new set of
> heads being added?  I'm thinking a higher failure rate, more risk to
> data or something like that.  I think this is a fairly new thing, last
> couple years or so maybe.  We all know how some new things don't work out.

I think this technology has actually been out for a long time. I'm sure 
I've heard of it ages ago.

Thing is, it's probably one of those things that's been available in 
high-end drives for years, but the cost-benefit ratio has been low so 
few people bought them. Now presumably the economics have changed.

If the actuators are mounted opposite each other, then they can't 
collide, and presumably can operate completely independent of each 
other. The costs of two of them were presumably just deemed not worth it.

An opposite niche (and rather apposite for you) was when I started 
buying disk drives. I think my first was a 2GB Bigfoot, followed by a 
6GB, and I bought several 18GBs for work. They were "old tech", 5.25" 
5200rpm in an era of 3.5" 7500rpm, but their capacities were huge and 
cheap. If all you wanted was storage, they were great. Most people 
thought the size and speed of the smaller drives was better value, even 
if it cost more per meg.

Cheers,
Wol

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

[Michael]

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

On Wednesday 13 November 2024 23:10:10 GMT Dale wrote:
> Howdy,
> 
> One of my PVs is about 83% full.  Time to add more space, soon anyway.
> I try not to go past 90%.  Anyway, I was looking at hard drives and
> noticed something new.  I think I saw one a while back but didn't look
> into it at the time.  I'm looking at 18TB drives, right now.  Some new
> Seagate drives have dual actuators.  Basically, they have two sets of
> heads.  In theory, if circumstances are right, it could read data twice
> as fast.  Of course, most of the time that won't be the case but it can
> happen often enough to make it get data a little faster.  Even a 25% or
> 30% increase gives Seagate something to brag about.  Another sales tool.
>  Some heavy data users wouldn't mind either.
> 
> My question is this.  Given they cost about $20 more, from what I've
> found anyway, is it worth it?  Is there a downside to this new set of
> heads being added?  I'm thinking a higher failure rate, more risk to
> data or something like that.  I think this is a fairly new thing, last
> couple years or so maybe.  We all know how some new things don't work out.
> 
> Just looking for thoughts and opinions, facts if someone has some.
> Failure rate compared to single actuator drives if there is such data.
> My searched didn't help me find anything useful.
> 
> Thanks.
> 
> Dale
> 
> :-)  :-)

I don't know much about these drives beyond what the OEM claims.  From what I 
read, I can surmise the following hypotheses:

These drives draw more power from your PSU and although they are filled with 
helium to mitigate against higher power/heat, they will require better cooling 
at the margin than a conventional drive.

Your system will use dev-libs/libaio to read the whole disk as a single SATA 
drive (a SAS port will read it as two separate LUNs).  The first 50% of LBAs 
will be accessed by the first head and the last 50% by the other head.  So 
far, so good.

Theoretically, I suspect this creates a higher probability of failure.  In the 
hypothetical scenario of a large sequential write where both heads are writing 
data of a single file, then both heads must succeed in their write operation.  
The cumulative probability of success of head A + head B is calculated as 
P(A⋂B).  As an example, if say the probability of a successful write of each 
head is 80%, the cumulative probability of both heads succeeding is only 64%:

0.8 * 0.8 = 0.64

As long as I didn't make any glaring errors, this simplistic thought 
experiment assumes all else being equal with a conventional single head drive, 
but it never is.  The reliability of a conventional non-helium filled drive 
may be lower to start with.  Seagate claim their Exos 2 reliability is 
comparable to other enterprise-grade hard drives, but I don't have any real 
world experience to share here.  I expect by the time enough reliability 
statistics are available, the OEMs would have moved on to different drive 
technologies.

When considering buying this drive you could look at the market segment needs 
and use cases Seagate/WD could have tried to address by developing and 
marketing this technology.  These drives are for cloud storage 
implementations, where higher IOPS, data density and speed of read/write is 
desired, while everything is RAID'ed and backed up.  The trade off is power 
usage and heat.

Personally, I tend to buy n-1 versions of storage solutions, for the following 
reasons:

1. Price per GB is cheaper.
2. Any bad news and rumours about novel failing technologies or unsuitable 
implementations (e.g. unmarked SMRs being used in NAS) tend to spread far and 
wide over time.
3. High volume sellers start offering discounts for older models.

However, I don't have a need to store the amount of data you do.  Most of my 
drives stay empty.  Here's a 4TB spinning disk with 3 OS and 9 partitions:

~ # gdisk -l /dev/sda | grep TiB
Disk /dev/sda: 7814037168 sectors, 3.6 TiB
Total free space is 6986885052 sectors (3.3 TiB)

HTH

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

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

[Dale]

Matt Jolly wrote:
> Hi Dale,
>
>> My question is this.  Given they cost about $20 more, from what I've
>> found anyway, is it worth it?  Is there a downside to this new set of
>> heads being added?  I'm thinking a higher failure rate, more risk to
>> data or something like that.  I think this is a fairly new thing, last
>> couple years or so maybe.  We all know how some new things don't work
>> out.
>
> At least one vendor has been trying to sell me on these recently,
> claiming higher bandwidth and better ability to seek. I have not yet
> actually used these.
>
>> Just looking for thoughts and opinions, facts if someone has some.
>> Failure rate compared to single actuator drives if there is such data.
>> My searched didn't help me find anything useful.
>
> There's no reason to suspect that these are going to be terrible, they
> appear to be the next step on the Seagate roadmap before HAMR drives
> hit the market in the coming years.
>
> I haven't seen much on the reliability side of things, however I
> wouldn't be too concerned, assuming that there's proper backup in
> place - Any other drive (including SSDs) could "just die" for a
> multitude of
> reasons.
>

Well, the PV I'm planning to put this on isn't backed up at all.  It's
torrent data.  If it is lost, hopefully I can get it back again.  Still,
I don't want to lose any drive or data if I can help it.  It's why I
always get cases that have good cooling.  My old Cooler Master HAF-932
had excellent hard drive cooling for the ones mounted on the bottom. 
The 5-1/4 bays not so much.  While running a bit warmer, it still cooled
good even when filled up.  My new Fractal Design Define 7 XL has even
better cooling in a way.  The hard drives are not as close to the fans
but it cools all mechanical drives.  Anyway, it was something new to me
and I was curious as to what it does.  Reading other replies, it sounds
like it is OK but as with anything, there can be issues. 

>> P. S.  My greens are growing like weeds.  Usually they ready to pick by
>> now but having to wait for the tree to be cut down and cut up delayed
>> that.  Should be ready by Christmas, I hope.  Oh, planted oats, clover,
>> kale and some other extra seeds I had in open area.  I saw a LARGE buck
>> deer the other night snacking on the oats.  My neighbor would rather see
>> it in his freezer tho.  o_0
>
> Hopefully there's some left for you!
>
> Cheers,
>
> Matt
>
>

1/3rd of my garden is for people.  Kale, collards, turnip and mustard
greens.  That is inside a electric fence to keep the deer out.  The open
part outside the fence is a mix of oats, clover and such.  I just grow
it to keep the soil erosion down, improve the organic matter and let the
deer have something to munch on, besides what is inside the fence.  I
did have to add another spool of fence tape tho.  Dang deer got in but
had trouble leaving.  He tore up my fence a bit.  I got the wires closer
together now so he won't be getting in again.  Funny thing, bucks tend
to tear up fences.  Does rarely do.  It's the antlers.  They get hung up
and the shocks makes a deer want to be somewhere else.  I can't blame
him tho.  Those shocks hurt, bad.  Several of them can easily kill a
deer sized animal, even a cow or horse. 

Time for my weekly Doctor visit.  Reply to others later on. 

Dale

:-)  :-) 

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

[Dale]

Wols Lists wrote:
> On 13/11/2024 23:10, Dale wrote:
>> My question is this.  Given they cost about $20 more, from what I've
>> found anyway, is it worth it?  Is there a downside to this new set of
>> heads being added?  I'm thinking a higher failure rate, more risk to
>> data or something like that.  I think this is a fairly new thing, last
>> couple years or so maybe.  We all know how some new things don't work
>> out.
>
> I think this technology has actually been out for a long time. I'm
> sure I've heard of it ages ago.
>
> Thing is, it's probably one of those things that's been available in
> high-end drives for years, but the cost-benefit ratio has been low so
> few people bought them. Now presumably the economics have changed.
>
> If the actuators are mounted opposite each other, then they can't
> collide, and presumably can operate completely independent of each
> other. The costs of two of them were presumably just deemed not worth it.
>
> An opposite niche (and rather apposite for you) was when I started
> buying disk drives. I think my first was a 2GB Bigfoot, followed by a
> 6GB, and I bought several 18GBs for work. They were "old tech", 5.25"
> 5200rpm in an era of 3.5" 7500rpm, but their capacities were huge and
> cheap. If all you wanted was storage, they were great. Most people
> thought the size and speed of the smaller drives was better value,
> even if it cost more per meg.
>
> Cheers,
> Wol
>
>


It may have been available for really expensive hard drives.  Those far
above what I'd be willing to pay and wouldn't look for.  I do find it
interesting tho.  Why not have three actuators?  Or four?  If they can
all fit in there and not hit each other, it does give the heads more
opportunities to be over needed data.  Then the port between drive and
controller, SATA or maybe SAS, likely becomes a bottle neck.  Of course,
you can only fit so many in there.  Two may be the limit.  Drives are
fairly small already.  Plus there is the heat problem. 

I remember seeing old drives that had I think 14" platters.  They had
large motors to spin them.  The controller was a separate thing too.  I
think their capacity was like 30 or 40MBs or so.  It usually took two
people to move one of those things.  The company I worked for upgraded
systems twice in the five years I worked for them.  Their fastest one
ran at a blazingly fast 25MHz.  It was RISC based, I think I spelled
that right.  It was a NCR system.  We used old Wyse terminals but that
new system was really fast.  Except when two or more of those Genicom
line printers were running.  I think they were the model 4440 or
something.  The printhead didn't move.  It was as wide as the page and
printed a whole line at a time, hence the name line printer.  They could
print far faster than a person could read.  Still, those systems are
nothing compared to what we have today.  Heck, my old video card in my
current rig likely has more computing power than the NCR system back
then, which could handle 200 to 300 users at a time.  How far we have
came. 

Those were the days tho. 

Dale

:-)  :-) 

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

[Dale]

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

Michael wrote:
> On Wednesday 13 November 2024 23:10:10 GMT Dale wrote:
>> Howdy,
>>
>> One of my PVs is about 83% full.  Time to add more space, soon anyway.
>> I try not to go past 90%.  Anyway, I was looking at hard drives and
>> noticed something new.  I think I saw one a while back but didn't look
>> into it at the time.  I'm looking at 18TB drives, right now.  Some new
>> Seagate drives have dual actuators.  Basically, they have two sets of
>> heads.  In theory, if circumstances are right, it could read data twice
>> as fast.  Of course, most of the time that won't be the case but it can
>> happen often enough to make it get data a little faster.  Even a 25% or
>> 30% increase gives Seagate something to brag about.  Another sales tool.
>>  Some heavy data users wouldn't mind either.
>>
>> My question is this.  Given they cost about $20 more, from what I've
>> found anyway, is it worth it?  Is there a downside to this new set of
>> heads being added?  I'm thinking a higher failure rate, more risk to
>> data or something like that.  I think this is a fairly new thing, last
>> couple years or so maybe.  We all know how some new things don't work out.
>>
>> Just looking for thoughts and opinions, facts if someone has some.
>> Failure rate compared to single actuator drives if there is such data.
>> My searched didn't help me find anything useful.
>>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-)
> I don't know much about these drives beyond what the OEM claims.  From what I 
> read, I can surmise the following hypotheses:
>
> These drives draw more power from your PSU and although they are filled with 
> helium to mitigate against higher power/heat, they will require better cooling 
> at the margin than a conventional drive.
>
> Your system will use dev-libs/libaio to read the whole disk as a single SATA 
> drive (a SAS port will read it as two separate LUNs).  The first 50% of LBAs 
> will be accessed by the first head and the last 50% by the other head.  So 
> far, so good.
>
> Theoretically, I suspect this creates a higher probability of failure.  In the 
> hypothetical scenario of a large sequential write where both heads are writing 
> data of a single file, then both heads must succeed in their write operation.  
> The cumulative probability of success of head A + head B is calculated as 
> P(A⋂B).  As an example, if say the probability of a successful write of each 
> head is 80%, the cumulative probability of both heads succeeding is only 64%:
>
> 0.8 * 0.8 = 0.64
>
> As long as I didn't make any glaring errors, this simplistic thought 
> experiment assumes all else being equal with a conventional single head drive, 
> but it never is.  The reliability of a conventional non-helium filled drive 
> may be lower to start with.  Seagate claim their Exos 2 reliability is 
> comparable to other enterprise-grade hard drives, but I don't have any real 
> world experience to share here.  I expect by the time enough reliability 
> statistics are available, the OEMs would have moved on to different drive 
> technologies.
>
> When considering buying this drive you could look at the market segment needs 
> and use cases Seagate/WD could have tried to address by developing and 
> marketing this technology.  These drives are for cloud storage 
> implementations, where higher IOPS, data density and speed of read/write is 
> desired, while everything is RAID'ed and backed up.  The trade off is power 
> usage and heat.
>
> Personally, I tend to buy n-1 versions of storage solutions, for the following 
> reasons:
>
> 1. Price per GB is cheaper.
> 2. Any bad news and rumours about novel failing technologies or unsuitable 
> implementations (e.g. unmarked SMRs being used in NAS) tend to spread far and 
> wide over time.
> 3. High volume sellers start offering discounts for older models.
>
> However, I don't have a need to store the amount of data you do.  Most of my 
> drives stay empty.  Here's a 4TB spinning disk with 3 OS and 9 partitions:
>
> ~ # gdisk -l /dev/sda | grep TiB
> Disk /dev/sda: 7814037168 sectors, 3.6 TiB
> Total free space is 6986885052 sectors (3.3 TiB)
>
> HTH

Sounds like my system may not can even handle one of these.  I'm not
sure my SATA ports support that stuff.  It sounds like this is not
something I really need anyway.  After all, I'm already spanning my data
over three drives.  I'm sure some data is coming from each drive.  No
way to really know for sure but makes sense. 

Do you have a link or something to a place that explains what parts of
the Seagate model number means?  I know ST is for Seagate.  The size is
next.  After that, everything I find is old and outdated.  I looked on
the Seagate website to but had no luck.  I figure someone made one,
somewhere.  A link would be fine.

Thanks.

Dale

:-)  :-) 

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

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

[Michael]

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

On Thursday 14 November 2024 17:00:07 GMT Dale wrote:
> Michael wrote:
> > On Wednesday 13 November 2024 23:10:10 GMT Dale wrote:
> >> Howdy,
> >> 
> >> One of my PVs is about 83% full.  Time to add more space, soon anyway.
> >> I try not to go past 90%.  Anyway, I was looking at hard drives and
> >> noticed something new.  I think I saw one a while back but didn't look
> >> into it at the time.  I'm looking at 18TB drives, right now.  Some new
> >> Seagate drives have dual actuators.  Basically, they have two sets of
> >> heads.  In theory, if circumstances are right, it could read data twice
> >> as fast.  Of course, most of the time that won't be the case but it can
> >> happen often enough to make it get data a little faster.  Even a 25% or
> >> 30% increase gives Seagate something to brag about.  Another sales tool.
> >> 
> >>  Some heavy data users wouldn't mind either.
> >> 
> >> My question is this.  Given they cost about $20 more, from what I've
> >> found anyway, is it worth it?  Is there a downside to this new set of
> >> heads being added?  I'm thinking a higher failure rate, more risk to
> >> data or something like that.  I think this is a fairly new thing, last
> >> couple years or so maybe.  We all know how some new things don't work
> >> out.
> >> 
> >> Just looking for thoughts and opinions, facts if someone has some.
> >> Failure rate compared to single actuator drives if there is such data.
> >> My searched didn't help me find anything useful.
> >> 
> >> Thanks.
> >> 
> >> Dale
> >> 
> >> :-)  :-)
> > 
> > I don't know much about these drives beyond what the OEM claims.  From
> > what I read, I can surmise the following hypotheses:
> > 
> > These drives draw more power from your PSU and although they are filled
> > with helium to mitigate against higher power/heat, they will require
> > better cooling at the margin than a conventional drive.
> > 
> > Your system will use dev-libs/libaio to read the whole disk as a single
> > SATA drive (a SAS port will read it as two separate LUNs).  The first 50%
> > of LBAs will be accessed by the first head and the last 50% by the other
> > head.  So far, so good.
> > 
> > Theoretically, I suspect this creates a higher probability of failure.  In
> > the hypothetical scenario of a large sequential write where both heads
> > are writing data of a single file, then both heads must succeed in their
> > write operation. The cumulative probability of success of head A + head B
> > is calculated as P(A⋂B).  As an example, if say the probability of a
> > successful write of each head is 80%, the cumulative probability of both
> > heads succeeding is only 64%:
> > 
> > 0.8 * 0.8 = 0.64
> > 
> > As long as I didn't make any glaring errors, this simplistic thought
> > experiment assumes all else being equal with a conventional single head
> > drive, but it never is.  The reliability of a conventional non-helium
> > filled drive may be lower to start with.  Seagate claim their Exos 2
> > reliability is comparable to other enterprise-grade hard drives, but I
> > don't have any real world experience to share here.  I expect by the time
> > enough reliability statistics are available, the OEMs would have moved on
> > to different drive technologies.
> > 
> > When considering buying this drive you could look at the market segment
> > needs and use cases Seagate/WD could have tried to address by developing
> > and marketing this technology.  These drives are for cloud storage
> > implementations, where higher IOPS, data density and speed of read/write
> > is
> > desired, while everything is RAID'ed and backed up.  The trade off is
> > power
> > usage and heat.
> > 
> > Personally, I tend to buy n-1 versions of storage solutions, for the
> > following reasons:
> > 
> > 1. Price per GB is cheaper.
> > 2. Any bad news and rumours about novel failing technologies or unsuitable
> > implementations (e.g. unmarked SMRs being used in NAS) tend to spread far
> > and wide over time.
> > 3. High volume sellers start offering discounts for older models.
> > 
> > However, I don't have a need to store the amount of data you do.  Most of
> > my drives stay empty.  Here's a 4TB spinning disk with 3 OS and 9
> > partitions:
> > 
> > ~ # gdisk -l /dev/sda | grep TiB
> > Disk /dev/sda: 7814037168 sectors, 3.6 TiB
> > Total free space is 6986885052 sectors (3.3 TiB)
> > 
> > HTH
> 
> Sounds like my system may not can even handle one of these.  I'm not
> sure my SATA ports support that stuff.

I think your PC would handle these fine.


> It sounds like this is not something I really need anyway.

Well, this is more to the point.  ;-)
 

> After all, I'm already spanning my data
> over three drives.  I'm sure some data is coming from each drive.  No
> way to really know for sure but makes sense. 
> 
> Do you have a link or something to a place that explains what parts of
> the Seagate model number means?  I know ST is for Seagate.  The size is
> next.  After that, everything I find is old and outdated.  I looked on
> the Seagate website to but had no luck.  I figure someone made one,
> somewhere.  A link would be fine.

This document is from 2011, I don't know if they changed their nomenclature 
since then.

https://www.seagate.com/files/staticfiles/docs/pdf/marketing/st-model-number-cheat-sheet-sc504-1-1102us.pdf


> Thanks.
> 
> Dale
> 
> :-)  :-) 

The only Seagate 7200RPM disk I have started playing up a month ago.  I now 
have to replace it.  :-(

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

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

[Frank Steinmetzger]

Am Donnerstag, 14. November 2024, 20:12:25 Mitteleuropäische Normalzeit 

> The only Seagate 7200RPM disk I have started playing up a month ago.  I now
> have to replace it.  :-(

The German tech bubble has a saying when it’s about Seagate: “Sie geht oder 
sie geht nicht”. It plays on the fact that “sie geht” (literally “she runs”¹, 
meaning “it works”) sounds very similar to “Seagate”. So the literal joke is 
“Either it works or it doesn’t”, and the meta joke is “Seagate or not 
Seagate”.

¹ hard disk (“die Festplatte”) has feminine grammatical gender in German

-- 
Grüße | Greetings | Salut | Qapla’
Just don’t ignore it.

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

[Frank Steinmetzger]

Am Donnerstag, 14. November 2024, 20:51:32 Mitteleuropäische Normalzeit 
schrieb Frank Steinmetzger:
> Am Donnerstag, 14. November 2024, 20:12:25 Mitteleuropäische Normalzeit
> 
> > The only Seagate 7200RPM disk I have started playing up a month ago.  I
> > now
> > have to replace it.  :-(
> 
> The German tech bubble has a saying when it’s about Seagate: “Sie geht oder
> sie geht nicht”. It plays on the fact that “sie geht” (literally “she
> runs”¹, meaning “it works”) sounds very similar to “Seagate”. So the
> literal joke is “Either it works or it doesn’t”, and the meta joke is
> “Seagate or not Seagate”.


Lol, writing the above text gave me the strange feeling of having written it 
before. So I looked into my archive and I have indeed: in June 2014 *and* in 
December 2020. 🫣

-- 
Grüße | Greetings | Salut | Qapla’
What do brushing teeth and voting have in common?
If you don’t do it, it becomes brown on its own.

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

[Dale]

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

Michael wrote:
> On Thursday 14 November 2024 17:00:07 GMT Dale wrote:
>> Michael wrote:
>>> On Wednesday 13 November 2024 23:10:10 GMT Dale wrote:
>>>> Howdy,
>>>>
>>>> One of my PVs is about 83% full.  Time to add more space, soon anyway.
>>>> I try not to go past 90%.  Anyway, I was looking at hard drives and
>>>> noticed something new.  I think I saw one a while back but didn't look
>>>> into it at the time.  I'm looking at 18TB drives, right now.  Some new
>>>> Seagate drives have dual actuators.  Basically, they have two sets of
>>>> heads.  In theory, if circumstances are right, it could read data twice
>>>> as fast.  Of course, most of the time that won't be the case but it can
>>>> happen often enough to make it get data a little faster.  Even a 25% or
>>>> 30% increase gives Seagate something to brag about.  Another sales tool.
>>>>
>>>>  Some heavy data users wouldn't mind either.
>>>>
>>>> My question is this.  Given they cost about $20 more, from what I've
>>>> found anyway, is it worth it?  Is there a downside to this new set of
>>>> heads being added?  I'm thinking a higher failure rate, more risk to
>>>> data or something like that.  I think this is a fairly new thing, last
>>>> couple years or so maybe.  We all know how some new things don't work
>>>> out.
>>>>
>>>> Just looking for thoughts and opinions, facts if someone has some.
>>>> Failure rate compared to single actuator drives if there is such data.
>>>> My searched didn't help me find anything useful.
>>>>
>>>> Thanks.
>>>>
>>>> Dale
>>>>
>>>> :-)  :-)
>>> I don't know much about these drives beyond what the OEM claims.  From
>>> what I read, I can surmise the following hypotheses:
>>>
>>> These drives draw more power from your PSU and although they are filled
>>> with helium to mitigate against higher power/heat, they will require
>>> better cooling at the margin than a conventional drive.
>>>
>>> Your system will use dev-libs/libaio to read the whole disk as a single
>>> SATA drive (a SAS port will read it as two separate LUNs).  The first 50%
>>> of LBAs will be accessed by the first head and the last 50% by the other
>>> head.  So far, so good.
>>>
>>> Theoretically, I suspect this creates a higher probability of failure.  In
>>> the hypothetical scenario of a large sequential write where both heads
>>> are writing data of a single file, then both heads must succeed in their
>>> write operation. The cumulative probability of success of head A + head B
>>> is calculated as P(A⋂B).  As an example, if say the probability of a
>>> successful write of each head is 80%, the cumulative probability of both
>>> heads succeeding is only 64%:
>>>
>>> 0.8 * 0.8 = 0.64
>>>
>>> As long as I didn't make any glaring errors, this simplistic thought
>>> experiment assumes all else being equal with a conventional single head
>>> drive, but it never is.  The reliability of a conventional non-helium
>>> filled drive may be lower to start with.  Seagate claim their Exos 2
>>> reliability is comparable to other enterprise-grade hard drives, but I
>>> don't have any real world experience to share here.  I expect by the time
>>> enough reliability statistics are available, the OEMs would have moved on
>>> to different drive technologies.
>>>
>>> When considering buying this drive you could look at the market segment
>>> needs and use cases Seagate/WD could have tried to address by developing
>>> and marketing this technology.  These drives are for cloud storage
>>> implementations, where higher IOPS, data density and speed of read/write
>>> is
>>> desired, while everything is RAID'ed and backed up.  The trade off is
>>> power
>>> usage and heat.
>>>
>>> Personally, I tend to buy n-1 versions of storage solutions, for the
>>> following reasons:
>>>
>>> 1. Price per GB is cheaper.
>>> 2. Any bad news and rumours about novel failing technologies or unsuitable
>>> implementations (e.g. unmarked SMRs being used in NAS) tend to spread far
>>> and wide over time.
>>> 3. High volume sellers start offering discounts for older models.
>>>
>>> However, I don't have a need to store the amount of data you do.  Most of
>>> my drives stay empty.  Here's a 4TB spinning disk with 3 OS and 9
>>> partitions:
>>>
>>> ~ # gdisk -l /dev/sda | grep TiB
>>> Disk /dev/sda: 7814037168 sectors, 3.6 TiB
>>> Total free space is 6986885052 sectors (3.3 TiB)
>>>
>>> HTH
>> Sounds like my system may not can even handle one of these.  I'm not
>> sure my SATA ports support that stuff.
> I think your PC would handle these fine.
>
>
>> It sounds like this is not something I really need anyway.
> Well, this is more to the point.  ;-)
>  
>
>> After all, I'm already spanning my data
>> over three drives.  I'm sure some data is coming from each drive.  No
>> way to really know for sure but makes sense. 
>>
>> Do you have a link or something to a place that explains what parts of
>> the Seagate model number means?  I know ST is for Seagate.  The size is
>> next.  After that, everything I find is old and outdated.  I looked on
>> the Seagate website to but had no luck.  I figure someone made one,
>> somewhere.  A link would be fine.
> This document is from 2011, I don't know if they changed their nomenclature 
> since then.
>
> https://www.seagate.com/files/staticfiles/docs/pdf/marketing/st-model-number-cheat-sheet-sc504-1-1102us.pdf
>
>
>> Thanks.
>>
>> Dale
>>
>> :-)  :-) 
> The only Seagate 7200RPM disk I have started playing up a month ago.  I now 
> have to replace it.  :-(


Yea, I found that one too.  I see drives with letters that are not
listed under Segment.  They got new stuff, or changed letters to trick
folks.  I emailed the company I usually buy drives from, they do server
stuff, but haven't heard back yet.  Could be, there isn't one for new
drives.  Could be they there to make it look like they mean something
but don't, again, to trick folks. 

I've had a Seagate, a Maxtor from way back and a Western Digital go
bad.  This is one reason I don't knock any drive maker.  Any of them can
produce a bad drive.  What matters, if they stand behind it and make it
good or not.  It's one thing that kinda gets on my nerves about SMR.  It
seems, sounds, like they tried to hide it from people to make money. 
Thing is, as some learned, they don't do well in a RAID and some other
situations.  Heck, they do OK reading but when writing, they can get
real slow when writing a lot of data.  Then you have to wait until it
gets done redoing things so that it is complete.  I still have that SMR
drive for a backup.  It completes the backup pretty quick, if it isn't
much data, but after it is done, it does that bumpy thing for a lot
longer than the copy process does.  I wish I never bought that thing. 
The one good thing, I can unmount it and unhook the SATA cable while it
finishes.  All it needs is power.  Still annoying tho.

Think I'll try for a 18TB drive with one actuator.  Oh, some info on my
data storage.  This doesn't include backup drives. 


root@Gentoo-1 / # dfc
FILESYSTEM               (=) USED      FREE (-)  %USED   USED AVAILABLE 
TOTAL MOUNTED ON              
/dev/root                [===-----------------]  11.4%  24.6G    348.0G
392.7G /                       
devtmpfs                 [--------------------]   0.0%   0.0B     10.0M 
10.0M /dev                    
tmpfs                    [=-------------------]   0.0%   1.7M     25.1G 
25.1G /run                    
efivarfs                 [=========-----------]  43.2%  50.3K     72.7K
128.0K +ys/firmware/efi/efivars
shm                      [=-------------------]   0.0% 136.0K     62.9G 
62.9G /dev/shm                
/dev/nvme0n1p2           [==------------------]   6.4% 137.5M     
9.2G   9.8G /boot                   
/dev/nvme0n1p4           [=====---------------]  20.9%  18.8G    139.3G
176.1G /var                    
+v/mapper/home2-home--lv [=====---------------]  21.5%   1.4T     
5.7T   7.2T /home                   
/dev/nvme0n1p1           [=-------------------]   0.0% 152.0K     
2.0G   2.0G /efi                    
+ev/mapper/datavg-datalv [=================---]  83.3%  34.6T      6.9T 
41.5T /home/dale/Desktop/Data 
tmpfs                    [=-------------------]   0.0%   4.0K     70.0G 
70.0G /var/tmp/portage        
tmpfs                    [=-------------------]   0.0%  44.0K     12.6G 
12.6G /run/user/1000          
/dev/mapper/crypt        [===============-----]  73.9%  34.8T     12.3T 
47.1T /home/dale/Desktop/Crypt
/dev/mapper/6tb-main     [=============-------]  61.2%   3.3T     
2.1T   5.4T /mnt/6tb-main           
SUM:                     [===============-----]  72.7%  74.2T     27.6T
102.0T
root@Gentoo-1 / # pvs -O vg_name
  PV         VG       Fmt  Attr PSize  PFree
  /dev/sde1  datavg   lvm2 a--  12.73t    0
  /dev/sdc1  datavg   lvm2 a--  14.55t    0
  /dev/sdb1  datavg   lvm2 a--  14.55t    0
  /dev/sda1  home2    lvm2 a--  <7.28t    0
  /dev/sdf1  vg.crypt lvm2 a--  16.37t    0
  /dev/sdd1  vg.crypt lvm2 a--  14.55t    0
  /dev/sdg1  vg.crypt lvm2 a--  16.37t    0
root@Gentoo-1 / #



That looks better in a Konsole.  Oooo.  I'm over 100TBs now.  O_O 

Dale

:-)  :-) 

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

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

[Rich Freeman]

On Thu, Nov 14, 2024 at 3:33 PM Dale <rdalek1967@gmail.com> wrote:
>
>
> I've had a Seagate, a Maxtor from way back and a Western Digital go bad.  This is one reason I don't knock any drive maker.  Any of them can produce a bad drive.

++

All the consumer drive manufacturers are in a super-price-conscious
market.  For the most part their drives work as advertised, and
basically all of them have made a model with an abysmal failure rate
at some point.  I think Backblaze still publishes their stats and I
don't think any manufacturer stood out when it comes to these cheaper
consumer drives.  The enterprise stuff probably is more reliable, but
for HDD I don't think it is worth it - just use RAID.

I've personally been trying to shift towards solid state.  Granted, it
is about double the price of large 5400RPM drives, but the performance
is incomparable.  I've also been moving more towards used enterprise
drives with PLP/etc and where I can find the drive endurance info on
the ebay listing.  You can typically pay about $50/TB for an
enterprise SSD - either SATA or NVMe.  You'll pay a bit more if you
want a high capacity drive (U.2 16+TB or whatever).  That's in part
because I've been shifting to Ceph which is pretty IOPS-sensitive.
However, it is nice that when I add/replace a drive the cluster
rebuilds in an hour at most with kinda shocking network IO.

I'll use cheap consumer SATA/M.2 SSDs for OS drives that are easily
reimaged.  I'll use higher performance M.2 for gaming rigs (mostly
read-oriented), and back it up.  Be aware that the consumer write
benchmarks only work for short bursts and fall to a fraction of the
advertisement for sustained writes - the enterprise write benchmarks
reflect sustained writes and you can run at that speed until the drive
dies.

-- 
Rich

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

[Wols Lists]

On 14/11/2024 20:33, Dale wrote:
> It's one thing that kinda gets on my nerves about SMR.  It seems, 
> sounds, like they tried to hide it from people to make money.  Thing is, 
> as some learned, they don't do well in a RAID and some other 
> situations.  Heck, they do OK reading but when writing, they can get 
> real slow when writing a lot of data.  Then you have to wait until it 
> gets done redoing things so that it is complete.

Incidentally, when I looked up HAMR (I didn't know what it was) it's 
touted as making SMR obsolete. I can see why ...

And dual actuator? I would have thought that would be good for SMR 
drives. Not that I have a clue how they work internally, but I would 
have thought it made sense to have zones and a streaming log-structured 
layout. So when the user is using it, you're filling up the zones, and 
then when the drive has "free time", it takes a full zone that has the 
largest "freed/dead space" and streams it to the current zone, one 
actuator to read and one to write. Indeed, it could possibly do that 
while the drive is being used ...

Cheers,
Wol

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

[Dale]

Rich Freeman wrote:
> On Thu, Nov 14, 2024 at 3:33 PM Dale <rdalek1967@gmail.com> wrote:
>>
>> I've had a Seagate, a Maxtor from way back and a Western Digital go bad.  This is one reason I don't knock any drive maker.  Any of them can produce a bad drive.
> ++
>
> All the consumer drive manufacturers are in a super-price-conscious
> market.  For the most part their drives work as advertised, and
> basically all of them have made a model with an abysmal failure rate
> at some point.  I think Backblaze still publishes their stats and I
> don't think any manufacturer stood out when it comes to these cheaper
> consumer drives.  The enterprise stuff probably is more reliable, but
> for HDD I don't think it is worth it - just use RAID.
>
> I've personally been trying to shift towards solid state.  Granted, it
> is about double the price of large 5400RPM drives, but the performance
> is incomparable.  I've also been moving more towards used enterprise
> drives with PLP/etc and where I can find the drive endurance info on
> the ebay listing.  You can typically pay about $50/TB for an
> enterprise SSD - either SATA or NVMe.  You'll pay a bit more if you
> want a high capacity drive (U.2 16+TB or whatever).  That's in part
> because I've been shifting to Ceph which is pretty IOPS-sensitive.
> However, it is nice that when I add/replace a drive the cluster
> rebuilds in an hour at most with kinda shocking network IO.
>
> I'll use cheap consumer SATA/M.2 SSDs for OS drives that are easily
> reimaged.  I'll use higher performance M.2 for gaming rigs (mostly
> read-oriented), and back it up.  Be aware that the consumer write
> benchmarks only work for short bursts and fall to a fraction of the
> advertisement for sustained writes - the enterprise write benchmarks
> reflect sustained writes and you can run at that speed until the drive
> dies.
>


The biggest downside to the large drives available now, even if SMART
tells you a drive is failing, you likely won't have time to copy the
data over to a new drive before it fails.  On a 18TB drive, using
pvmove, it can take a long time to move data.  I think the last time I
did it, it took like two days.  Usually SMART is more like a 24 hour
warning.  Of course with some failures, you get no warning at all. 
SMART can't detect all modes of failure. 

Wol has a good point too.  What they trying to do is compete with SSD if
they can.  SSD, NVME and such are pricey if you need to store bulk
amounts of data.  I don't even want to think what it would cost to put
all my 100TBs or so on SSD or NVME drives.  WOW!!! 

Dale

:-)  :-) 

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

[Peter Humphrey]

On Thursday 14 November 2024 19:55:19 GMT Frank Steinmetzger wrote:

> Lol, writing the above text gave me the strange feeling of having written it
> before. So I looked into my archive and I have indeed: in June 2014 *and*
> in December 2020. 🫣

Tiresomely repetitious, then...

:)

-- 
Regards,
Peter.

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

[Peter Humphrey]

On Thursday 14 November 2024 16:48:56 GMT Dale wrote:

> I remember seeing old drives that had I think 14" platters.  They had
> large motors to spin them.  The controller was a separate thing too.  I
> think their capacity was like 30 or 40MBs or so.  It usually took two
> people to move one of those things.  The company I worked for upgraded
> systems twice in the five years I worked for them.  Their fastest one
> ran at a blazingly fast 25MHz.  It was RISC based, I think I spelled
> that right.

"Reduced instruction set computing." Hyphenate as you like.

In the 70s and 80s the national grid control centre in this country used three 
2MB disks, any one or two of which could be online at any time. I can't tell 
you the platter size, but they were mounted in cabinets about 5' long, 3'6" 
tall and 2' wide. Each. Our training included servicing the air circulation 
system and its filters. I still remember the aluminium-alloy casings.

The two computers were Ferranti Argus 500 minis, one on-line, one hot standby, 
with 16MB of 2-microsecond core store, with the applications written in-house. 
The operating system was primitive compared with today, also written by us. 
Nothing relocatable; programs and data lived in strictly defined regions.  They 
drove (I think) 24 analogue vector-drawing displays (no raster to modulate) in 
the control room upstairs. They never could display a perfect circle - there 
was always a tiny gap. The D/A converters were big beasts. The systems had 
been developed from earlier ones in nuclear submarines. We didn't have their 
big, circular consoles though.

I hate to think how many miles of 8-hole tape I wound and rewound. Thank 
goodness we didn't have to cope with 80-column punched cards (Hollerith?) as 
the ivory-tower, batch-processing mainframe people did.

We used to show visitors around, some from American utility companies, who 
always asked "yes, nice display driver, but where are your main machines?

Great things be could achieved with assembler and first-class people. More 
efficient than just throwing money at a problem until it gives in.

> Those were the days tho. 

Indeed, the best. Mind you, nostalgia isn't what it used to be...

Time for bed, said Zebedee.

-- 
Regards,
Peter.

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

[Rich Freeman]

On Thu, Nov 14, 2024 at 6:10 PM Dale <rdalek1967@gmail.com> wrote:
>
> The biggest downside to the large drives available now, even if SMART
> tells you a drive is failing, you likely won't have time to copy the
> data over to a new drive before it fails.  On a 18TB drive, using
> pvmove, it can take a long time to move data.

Very true.  This is why I'm essentially running RAID6.  Well, that and
for various reasons you don't want to allow writes to Ceph without at
least one drive worth of redundancy, so having an extra replica means
that you can lose one and remain read-write, and then if you lose a
second during recovery you might be read-only but you still have data
integrity.  (Don't want to get into details - it is a Ceph-specific
issue.)

> I don't even want to think what it would cost to put
> all my 100TBs or so on SSD or NVME drives.  WOW!!!

# kubectl rook-ceph ceph osd df class ssd
ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP
META     AVAIL    %USE   VAR   PGS  STATUS
 8    ssd   6.98630   1.00000  7.0 TiB  1.7 TiB  1.7 TiB   63 MiB  3.9
GiB  5.3 TiB  24.66  1.04  179      up
 4    ssd   1.74660   1.00000  1.7 TiB  465 GiB  462 GiB   16 MiB  2.5
GiB  1.3 TiB  25.99  1.10   45      up
12    ssd   1.74660   1.00000  1.7 TiB  547 GiB  545 GiB   30 MiB  2.1
GiB  1.2 TiB  30.57  1.29   52      up
 1    ssd   6.98630   1.00000  7.0 TiB  1.7 TiB  1.7 TiB   50 MiB  4.2
GiB  5.3 TiB  24.42  1.03  177      up
 5    ssd   6.98630   1.00000  7.0 TiB  1.8 TiB  1.8 TiB   24 MiB  5.0
GiB  5.2 TiB  25.14  1.07  180      up
 3    ssd   1.74660   1.00000  1.7 TiB  585 GiB  583 GiB   18 MiB  2.0
GiB  1.2 TiB  32.70  1.39   57      up
21    ssd   1.74660   1.00000  1.7 TiB  470 GiB  468 GiB   27 MiB  1.9
GiB  1.3 TiB  26.26  1.11   52      up
 9    ssd   1.74660   1.00000  1.7 TiB  506 GiB  504 GiB   11 MiB  2.0
GiB  1.3 TiB  28.29  1.20   49      up
18    ssd   1.74660   1.00000  1.7 TiB  565 GiB  563 GiB   16 MiB  1.7
GiB  1.2 TiB  31.59  1.34   55      up
10    ssd   1.74660   1.00000  1.7 TiB  490 GiB  489 GiB   28 MiB  1.6
GiB  1.3 TiB  27.42  1.16   53      up
22    ssd   1.74660   1.00000  1.7 TiB  479 GiB  478 GiB   19 MiB  1.7
GiB  1.3 TiB  26.80  1.14   50      up
19    ssd  13.97249   1.00000   14 TiB  2.3 TiB  2.3 TiB   87 MiB  5.2
GiB   12 TiB  16.81  0.71  262      up
                        TOTAL   49 TiB   12 TiB   12 TiB  388 MiB   34
GiB   37 TiB  23.61

I'm getting there.  Granted, at 3+2 erasure coding that's only a bit
over 30TiB usable space.

-- 
Rich

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

[Dale]

Rich Freeman wrote:
> On Thu, Nov 14, 2024 at 6:10 PM Dale <rdalek1967@gmail.com> wrote:
>> The biggest downside to the large drives available now, even if SMART
>> tells you a drive is failing, you likely won't have time to copy the
>> data over to a new drive before it fails.  On a 18TB drive, using
>> pvmove, it can take a long time to move data.
> Very true.  This is why I'm essentially running RAID6.  Well, that and
> for various reasons you don't want to allow writes to Ceph without at
> least one drive worth of redundancy, so having an extra replica means
> that you can lose one and remain read-write, and then if you lose a
> second during recovery you might be read-only but you still have data
> integrity.  (Don't want to get into details - it is a Ceph-specific
> issue.)


I think I did some math on this once.  I'm not positive on this and it
could vary depending on system ability of moving data.  I think about
8TB is as large as you want if you get a 24 hour notice from SMART and
see that notice fairly quickly to act on.  Anything beyond that and you
may not have enough time to move data, if the data is even good still. 


>> I don't even want to think what it would cost to put
>> all my 100TBs or so on SSD or NVME drives.  WOW!!!
> # kubectl rook-ceph ceph osd df class ssd
> ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP
> META     AVAIL    %USE   VAR   PGS  STATUS
>  8    ssd   6.98630   1.00000  7.0 TiB  1.7 TiB  1.7 TiB   63 MiB  3.9
> GiB  5.3 TiB  24.66  1.04  179      up
>  4    ssd   1.74660   1.00000  1.7 TiB  465 GiB  462 GiB   16 MiB  2.5
> GiB  1.3 TiB  25.99  1.10   45      up
> 12    ssd   1.74660   1.00000  1.7 TiB  547 GiB  545 GiB   30 MiB  2.1
> GiB  1.2 TiB  30.57  1.29   52      up
>  1    ssd   6.98630   1.00000  7.0 TiB  1.7 TiB  1.7 TiB   50 MiB  4.2
> GiB  5.3 TiB  24.42  1.03  177      up
>  5    ssd   6.98630   1.00000  7.0 TiB  1.8 TiB  1.8 TiB   24 MiB  5.0
> GiB  5.2 TiB  25.14  1.07  180      up
>  3    ssd   1.74660   1.00000  1.7 TiB  585 GiB  583 GiB   18 MiB  2.0
> GiB  1.2 TiB  32.70  1.39   57      up
> 21    ssd   1.74660   1.00000  1.7 TiB  470 GiB  468 GiB   27 MiB  1.9
> GiB  1.3 TiB  26.26  1.11   52      up
>  9    ssd   1.74660   1.00000  1.7 TiB  506 GiB  504 GiB   11 MiB  2.0
> GiB  1.3 TiB  28.29  1.20   49      up
> 18    ssd   1.74660   1.00000  1.7 TiB  565 GiB  563 GiB   16 MiB  1.7
> GiB  1.2 TiB  31.59  1.34   55      up
> 10    ssd   1.74660   1.00000  1.7 TiB  490 GiB  489 GiB   28 MiB  1.6
> GiB  1.3 TiB  27.42  1.16   53      up
> 22    ssd   1.74660   1.00000  1.7 TiB  479 GiB  478 GiB   19 MiB  1.7
> GiB  1.3 TiB  26.80  1.14   50      up
> 19    ssd  13.97249   1.00000   14 TiB  2.3 TiB  2.3 TiB   87 MiB  5.2
> GiB   12 TiB  16.81  0.71  262      up
>                         TOTAL   49 TiB   12 TiB   12 TiB  388 MiB   34
> GiB   37 TiB  23.61
>
> I'm getting there.  Granted, at 3+2 erasure coding that's only a bit
> over 30TiB usable space.
>


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.  I checked and I have some 56,000 videos.  That
doesn't include Youtube videos.  This is also why I wanted to use that
checksum script. 

I do wish there was a easy way to make columns work when we copy and
paste into email.  :/ 

Dale

:-)  :-) 

[gentoo-user] Hollerith (was: Seagate hard drives with dual actuators)

[karl]

Peter Humphrey:
...
> I hate to think how many miles of 8-hole tape I wound and rewound. Thank 
> goodness we didn't have to cope with 80-column punched cards (Hollerith?) as 
> the ivory-tower, batch-processing mainframe people did.
...

 Hollerith was the founder of the company which later became IBM.
 There are two things named as Hollerith, the cards which later 
 developed into the IBM 80-col. card, and the constants representing
 text/strings/characters in early fortran.

 https://en.wikipedia.org/wiki/Hollerith

 Fortran was my first language, I still have unpunched cards left,
 perfect as bookmarks.

///

 Old style secondary storage (boxes of punched cards):

 https://en.wikipedia.org/wiki/File:Photograph_of_Federal_Records_Center,_Alexandria,_Virginia_(34877725360).jpg

Regards,
/Karl Hammar

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

[Michael]

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

On Thursday 14 November 2024 22:38:59 GMT Wols Lists wrote:
> On 14/11/2024 20:33, Dale wrote:
> > It's one thing that kinda gets on my nerves about SMR.  It seems,
> > sounds, like they tried to hide it from people to make money.  Thing is,
> > as some learned, they don't do well in a RAID and some other
> > situations.  Heck, they do OK reading but when writing, they can get
> > real slow when writing a lot of data.  Then you have to wait until it
> > gets done redoing things so that it is complete.
> 
> Incidentally, when I looked up HAMR (I didn't know what it was) it's
> touted as making SMR obsolete. I can see why ...

aaaand .... it's gone!  LOL!  Apparently, HDMR is on the cards to replace 
HAMR.


> And dual actuator? I would have thought that would be good for SMR
> drives. Not that I have a clue how they work internally, but I would
> have thought it made sense to have zones and a streaming log-structured
> layout. So when the user is using it, you're filling up the zones, and
> then when the drive has "free time", it takes a full zone that has the
> largest "freed/dead space" and streams it to the current zone, one
> actuator to read and one to write. Indeed, it could possibly do that
> while the drive is being used ...
> 
> Cheers,
> Wol

As I understand it the dual actuator drives are like two separate drives 
placed inside the same casing, but being accessed in parallel by their 
respective head, hence the higher IOPS.  The helium allows thinner platters 
which makes it possible to have higher total storage capacity within the same 
physical size.

The SMR is more complicated in technological terms, with its overlapping 
multilayered recording.  It achieves higher storage density than conventional 
drives, but with lower IOPS on writing operations once their cache is 
exhausted.

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

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

[Wols Lists]

On 15/11/2024 00:18, Peter Humphrey wrote:
> In the 70s and 80s the national grid control centre in this country used three
> 2MB disks, any one or two of which could be online at any time. I can't tell
> you the platter size, but they were mounted in cabinets about 5' long, 3'6"
> tall and 2' wide. Each. Our training included servicing the air circulation
> system and its filters. I still remember the aluminium-alloy casings.

When I started in the early 80s, the company I worked for had those 19" 
platters. We had one drive cabinet with one fixed and one removable 
platter, 16MB each for a 32MB drive. And, iirc, an 80MB drive.

When we got one of those 300MB drives with "19 platters" disk packs, wow!

If anybody thinks those sizes don't quite make sense, I think the 
platters actually stored 16MB/side, but one side per pack was used for 
tracking data. So the 80BM drive had 3 physical platters (5 usable 
sides), and the the 300MB had 10 physical platters (19 usable sides).

I got contracted out to an oil exploration company that had a Perkin 
Elmer mainframe and a room of those 300 MB drives ...

And wrote a plotting program - in Fortran - that plotted rock 
cross-sections. My programs always forced explicit declaration, but 
stuck with the implicit conventions, so when I wanted variables "left" 
and "right" I was wondering what to call them. I settled on SINIST and 
DEXTER, and of course, when my boss at the client looked at my code he'd 
studied latin ... those were the days ...

 > Great things be could achieved with assembler and first-class people.
 > More efficient than just throwing money at a problem until it gives
 > in.

The problem with that is that it forces everyone else to just throw 
money at it too ... We're using Oracle and BigQuery at work, and oh my 
god do I hanker for Pick. 32 users hammering a 1GB database, with a 
MIPS3000 processor in the database server (the same chip that powered 
the Playstation 1). Even when the hard disk was going 19 to the dozen, 
the users never complained that it was slow - they might have remarked, 
because it was noticeable, but not at the "go make a cup of tea" level...

 > Indeed, the best. Mind you, nostalgia isn't what it used to be...

Of course...

Cheers,
Wol

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

[Michael]

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

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.


> I checked and I have some 56,000 videos.  That
> doesn't include Youtube videos.  This is also why I wanted to use that
> checksum script. 
> 
> I do wish there was a easy way to make columns work when we copy and
> paste into email.  :/ 
> 
> Dale
> 
> :-)  :-) 


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

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

[Frank Steinmetzger]

Am Freitag, 15. November 2024, 06:53:53 Mitteleuropäische Normalzeit schrieb 
Dale:
> Rich Freeman wrote:
> > On Thu, Nov 14, 2024 at 6:10 PM Dale <rdalek1967@gmail.com> wrote:
> >> The biggest downside to the large drives available now, even if SMART
> >> tells you a drive is failing, you likely won't have time to copy the
> >> data over to a new drive before it fails.  On a 18TB drive, using
> >> pvmove, it can take a long time to move data.
> >> […]
> 
> I think I did some math on this once.  I'm not positive on this and it
> could vary depending on system ability of moving data.  I think about
> 8TB is as large as you want if you get a 24 hour notice from SMART and
> see that notice fairly quickly to act on.  Anything beyond that and you
> may not have enough time to move data, if the data is even good still.

I have 6 TB drives in my NAS, good ol’ WD Reds from before SMR time. When I 
scrub them, i.e. read the whole of their data out sequentially at 80 % 
capacity (so effectively around 5 TB), it takes 10½ hours. Looks like your 
math adds up. Maybe 10 or even 12 TB would also still work in that time 
window. Recently I switched from ZFS’s Raid6 to Raid5 because of said 80 % 
occupancy and I needed more space, but had neither any free slots left nor 
wanted to buy new hardware. Fingers crossed …


> >> I don't even want to think what it would cost to put
> >> all my 100TBs or so on SSD or NVME drives.  WOW!!!
> > 
> > # kubectl rook-ceph ceph osd df class ssd
> > ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP
> > META     AVAIL    %USE   VAR   PGS  STATUS
> > 
> >  8    ssd   6.98630   1.00000  7.0 TiB  1.7 TiB  1.7 TiB   63 MiB  3.9
> > 
> > GiB  5.3 TiB  24.66  1.04  179      up
> > […]
> 
> I do wish there was a easy way to make columns work when we copy and
> paste into email.  :/ 

For special cases like this I think we wouldn’t mind using HTML mail. Or 
simply disable automatic wrapping and use long lines of text for the entire 
message. The client can then decide where to wrap.

I know it’s like a religious debate whether to wrap at <80 columns (please 
don’t start one here), but there is actually an automatism for this: if you 
end the line with a space, you can still wrap you text statically at <80 
columns, but the space tells the client that it may wrap here or not. I forgot 
the name of it though, I learned about it in the mutt user group.

For me it’s easier: as I use vim in mutt. I usually let it do the wrapping for 
me (including the mechanism I described). But I can disable wrapping on-the-
fly, so I can paste longer terminal output.

> Dale
> 
> :-)  :-) 

-- 
Grüße | Greetings | Salut | Qapla’
Feet are fat, lumpy hands with short, stubby fingers.

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

[Dale]

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

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.  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.  Another thing, I may switch to RAID one
of these days.  If I do, that drive isn't a good option. 

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. 

This is the drive model I'm looking at.  ST18000NM000J  I don't think it
has its own encryption or anything and is a drive that will work in my
situation.  I don't know what the last bits mean tho but saw somewhere
that 000 means no encryption.  Not sure on the J part on the end.  I did
find where I bought other sizes of drives with the same bit on the end. 
They seem to work fine, so far anyway.  I order my drives from here: 

https://serverpartdeals.com/

I've bought what falls into the used category and them have only a few
power up hours on them.  A lot of the time, it is less than 10 hours.  I
have seen 3 or 4 hours or less with SMART a few times.

Now to get my money saved up.  Won't be long.  Another $200 but lots of
data. 

Dale

:-)  :-) 

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

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

[Dale]

Frank Steinmetzger wrote:
> Am Freitag, 15. November 2024, 06:53:53 Mitteleuropäische Normalzeit schrieb 
> Dale:
>> Rich Freeman wrote:
>>> On Thu, Nov 14, 2024 at 6:10 PM Dale <rdalek1967@gmail.com> wrote:
>>>> The biggest downside to the large drives available now, even if SMART
>>>> tells you a drive is failing, you likely won't have time to copy the
>>>> data over to a new drive before it fails.  On a 18TB drive, using
>>>> pvmove, it can take a long time to move data.
>>>> […]
>> I think I did some math on this once.  I'm not positive on this and it
>> could vary depending on system ability of moving data.  I think about
>> 8TB is as large as you want if you get a 24 hour notice from SMART and
>> see that notice fairly quickly to act on.  Anything beyond that and you
>> may not have enough time to move data, if the data is even good still.
> I have 6 TB drives in my NAS, good ol’ WD Reds from before SMR time. When I 
> scrub them, i.e. read the whole of their data out sequentially at 80 % 
> capacity (so effectively around 5 TB), it takes 10½ hours. Looks like your 
> math adds up. Maybe 10 or even 12 TB would also still work in that time 
> window. Recently I switched from ZFS’s Raid6 to Raid5 because of said 80 % 
> occupancy and I needed more space, but had neither any free slots left nor 
> wanted to buy new hardware. Fingers crossed …
>

Given the notice could be sent when one is not looking and may not be
seen for a while, I'd error on smaller not larger.  Some systems could
be faster than others as well.  Since I use LVM so much, I time pvmove. 
That is what I would use anyway.  If one uses some other tool, it would
be good to time with that tool.  It could be faster or slower.  I
suspect the drive would likely be the limit but one needs to test to be
sure. 


>>>> I don't even want to think what it would cost to put
>>>> all my 100TBs or so on SSD or NVME drives.  WOW!!!
>>> # kubectl rook-ceph ceph osd df class ssd
>>> ID  CLASS  WEIGHT    REWEIGHT  SIZE     RAW USE  DATA     OMAP
>>> META     AVAIL    %USE   VAR   PGS  STATUS
>>>
>>>  8    ssd   6.98630   1.00000  7.0 TiB  1.7 TiB  1.7 TiB   63 MiB  3.9
>>>
>>> GiB  5.3 TiB  24.66  1.04  179      up
>>> […]
>> I do wish there was a easy way to make columns work when we copy and
>> paste into email.  :/ 
> For special cases like this I think we wouldn’t mind using HTML mail. Or 
> simply disable automatic wrapping and use long lines of text for the entire 
> message. The client can then decide where to wrap.
>
> I know it’s like a religious debate whether to wrap at <80 columns (please 
> don’t start one here), but there is actually an automatism for this: if you 
> end the line with a space, you can still wrap you text statically at <80 
> columns, but the space tells the client that it may wrap here or not. I forgot 
> the name of it though, I learned about it in the mutt user group.
>
> For me it’s easier: as I use vim in mutt. I usually let it do the wrapping for 
> me (including the mechanism I described). But I can disable wrapping on-the-
> fly, so I can paste longer terminal output.
>
>> Dale
>>
>> :-)  :-) 


I've tried to make things look right before and most of the time, it
either gets worse or does something really weird, it double wrapped
once.  I never sent that double wrapped one but it was weird looking.  I
have Seamonkey set to convert to text only to anything sent to a
@gentoo.org address.  Even if I compose it in HTML, it will convert it
to text only when sending.  I have thought of using screenshots,
images.  The bad thing there, can't copy and paste it.  Plus, some don't
like large emails and images can't make one larger than usual. 

It seems one can't win for losing.  LOL 

Dale

:-)  :-) 

P. S.  I feel like I am forgetting to mention something.  My poor
brain.  :-( 

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

[Michael]

[-- 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 --]

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

[Dale]

[-- 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 --]

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

[Rich Freeman]

On Fri, Nov 15, 2024 at 10:35 AM Michael <confabulate@kintzios.com> wrote:
>
> 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?  :-/

IMO a host-managed solution is likely to be the only thing that will
work reliably.  If the drive supports discard/trim MAYBE a dumber
drive might be able to be used with the right filesystem.  Even if
you're doing "write-once" workloads any kind of metadata change is
going to cause random writes unless the filesystem was designed for
SMR.  Ideally you'd store metadata on a non-SMR device, though it
isn't strictly necessary with a log-based approach.

If the SMR drive tries really hard to not look like an SMR drive and
doesn't support discard/trim then even an SMR-aware solution probably
won't be able to use it effectively.  The drive is going to keep doing
read-before-write cycles to preserve data even if there is nothing
useful to preserve.

--
Rich

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

[Michael]

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

On Friday 15 November 2024 22:13:27 GMT Rich Freeman wrote:
> On Fri, Nov 15, 2024 at 10:35 AM Michael <confabulate@kintzios.com> wrote:
> > 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?  :-/
> 
> IMO a host-managed solution is likely to be the only thing that will
> work reliably.  

I think HM-SMRs may be used in commercial applications and DM-SMRs fed to the 
unaware retail consumer, not that we can tell without the OEMs providing this 
rather vital piece of information.  I assume (simplistically) with DM-SMRs the 
discard-garbage collection is managed wholly by the onboard drive controller, 
while with HM-SMRs the OS will signal the drive to start trimming when the 
workload is low in order to distribute the timing overheads to the system's 
idle time.


> If the drive supports discard/trim MAYBE a dumber
> drive might be able to be used with the right filesystem.  Even if
> you're doing "write-once" workloads any kind of metadata change is
> going to cause random writes unless the filesystem was designed for
> SMR.  Ideally you'd store metadata on a non-SMR device, though it
> isn't strictly necessary with a log-based approach.

I've considered the flash storage trim operation to be loosely like the SMR 
behaviour of read-modify-write and similarly susceptible to write-
amplification, but with SSD the write speed is so much faster it doesn't cause 
the same noticeable slowdown as with SMR.
 

> If the SMR drive tries really hard to not look like an SMR drive and
> doesn't support discard/trim then even an SMR-aware solution probably
> won't be able to use it effectively.  The drive is going to keep doing
> read-before-write cycles to preserve data even if there is nothing
> useful to preserve.
> 
> --
> Rich

Sure, trimming nudges by the OS won't have an effect on the DM-SMR drive since 
small changes to shingled bands are managed internally by the onboard STL 
controller and the persistent SMR cache.  However, there are some things a 
filesystem driver can still provide to improve performance. For example, 
compression, caching-batching to facilitate sequential writing directly in 
whole bands rather than random small regions within a band, etc.  In the case 
of ext4 'lazy writeback journaling' the allocated journaling space is 
increased upfront and the metadata are written once only with a mapping 
inserted in memory to join the location of the metadata in the journal itself 
instead of writing it twice.  The two links at the bottom of this page explain 
it better:

https://www.usenix.org/conference/fast17/technical-sessions/presentation/
aghayev

I'm not sure if this happens automatically, or if some mkfs and mount 
option(s) need to be called upon.  With up to 30x faster write speed, perhaps 
this is something Dale may want to investigate and experiment with.

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

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

[Rich Freeman]

On Sat, Nov 16, 2024 at 6:02 AM Michael <confabulate@kintzios.com> wrote:
>
> I assume (simplistically) with DM-SMRs the
> discard-garbage collection is managed wholly by the onboard drive controller,
> while with HM-SMRs the OS will signal the drive to start trimming when the
> workload is low in order to distribute the timing overheads to the system's
> idle time.

I'll admit I haven't looked into the details as I have no need for SMR
and there aren't any good FOSS solutions for using it that I'm aware
of (just a few that might be slightly less terrible).  However, this
doesn't seem correct for two reasons:

First, I'm not sure why HM-SMR would even need a discard function.
The discard command is used to tell a drive that a block is safe to
overwrite without preservation.  A host-managed SMR drive doesn't need
to know what data is disposable and what data is not.  It simply needs
to write data when the host instructs it to do so, destroying other
data in the process, and it is the host's job to not destroy anything
it cares about.  If a write requires a prior read, then the host needs
to first do the read, then adjust the written data appropriately so
that nothing is lost.

Second, there is no reason that any drive of any kind (SMR or SSD)
NEEDS to do discard/trim operations when the drive is idle, because
discard/trim is entirely a metadata operation that doesn't require IO
with the drive data itself.  Now, some drives might CHOOSE to
implement it that way, but they don't have to.  On an SSD, a discard
command does not mean that the drive needs to erase or move any data
at all.  It just means that if there is a subsequent erase that would
impact that block, it isn't necessary to first read the data and
re-write it afterwards.  A discard could be implemented entirely in
non-volatile metadata storage, such as with a bitmap.  For a DM-SMR
using flash for this purpose would make a lot of sense - you wouldn't
need much of it.

This is probably why you have endless arguing online about whether
discard/trim is helpful for SSDs. It completely depends on how the
drive implements the command.  The drives I've owned can discard
blocks without any impact on IO, but I've heard some have a terrible
impact on IO.  It is just like how you can complete the same sort
operation in seconds or hours depending on how dumb your sorting
algorithm is.

In any case, to really take advantage of SMR the OS needs to
understand exactly how to structure its writes so as to not take a
penalty, and that requires information about the implementation of the
storage that isn't visible in a DM-SMR.  Sure, some designs will do
better on SMR even without this information, but I don't think they'll
ever be all that efficient.  It is no different from putting f2fs on a
flash drive with a brain-dead discard implementation - even if the OS
does all its discards in nice consolidated contiguous operations it
doesn't mean that the drive will handle that in milliseconds instead
of just blocking all IO for an hour - sure, the drive COULD do the
operation quickly, but that doesn't mean that the firmware designers
didn't just ignore the simplest use case in favor of just optimizing
around the assumption that NTFS is the only filesystem in the world.

-- 
Rich

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

[Michael]

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

On Saturday 16 November 2024 14:36:02 GMT Rich Freeman wrote:
> On Sat, Nov 16, 2024 at 6:02 AM Michael <confabulate@kintzios.com> wrote:
> > I assume (simplistically) with DM-SMRs the
> > discard-garbage collection is managed wholly by the onboard drive
> > controller, while with HM-SMRs the OS will signal the drive to start
> > trimming when the workload is low in order to distribute the timing
> > overheads to the system's idle time.
> 
> I'll admit I haven't looked into the details as I have no need for SMR
> and there aren't any good FOSS solutions for using it that I'm aware
> of (just a few that might be slightly less terrible).  However, this
> doesn't seem correct for two reasons:
> 
> First, I'm not sure why HM-SMR would even need a discard function.
> The discard command is used to tell a drive that a block is safe to
> overwrite without preservation.  A host-managed SMR drive doesn't need
> to know what data is disposable and what data is not.  It simply needs
> to write data when the host instructs it to do so, destroying other
> data in the process, and it is the host's job to not destroy anything
> it cares about.  If a write requires a prior read, then the host needs
> to first do the read, then adjust the written data appropriately so
> that nothing is lost.

As I understand it from reading various articles, the constraint of having to 
write sequentially a whole band when a random block changes within a band 
works the same on both HM-SMR and the more common DM-SMR.  What differs with 
HM-SMR instructions is the host is meant to take over the management of random 
writes and submit these as sequential whole band streams to the drive to be 
committed without a read-modify-write penalty.  I suppose for the host to have 
to read the whole band first from the drive, modify it and then submit it to 
the drive to write it as a whole band will be faster than letting the drive 
manage this operation internally and getting its internal cache full.  This 
will not absolve the drive firmware from having to manage its own trim 
operations and the impact metadata changes could have on the drive, but some 
timing optimisation is perhaps reasonable.  I can't recall where I read this 
bit - perhaps some presentation on XFS or ext4 - not sure.


> Second, there is no reason that any drive of any kind (SMR or SSD)
> NEEDS to do discard/trim operations when the drive is idle, because
> discard/trim is entirely a metadata operation that doesn't require IO
> with the drive data itself.  Now, some drives might CHOOSE to
> implement it that way, but they don't have to.  On an SSD, a discard
> command does not mean that the drive needs to erase or move any data
> at all.  It just means that if there is a subsequent erase that would
> impact that block, it isn't necessary to first read the data and
> re-write it afterwards.  A discard could be implemented entirely in
> non-volatile metadata storage, such as with a bitmap.  For a DM-SMR
> using flash for this purpose would make a lot of sense - you wouldn't
> need much of it.

I don't know if SMRs use flash to record their STL status and data allocation 
between their persistent cache and shingled storage space.  I would think yes, 
or at least they ought to.  Without metadata written to different media, for 
such a small random write to take place atomically a whole SMR band will be 
read, modified in memory, written to a new temporary location and finally 
overwrite the original SMR band.


> This is probably why you have endless arguing online about whether
> discard/trim is helpful for SSDs. It completely depends on how the
> drive implements the command.  The drives I've owned can discard
> blocks without any impact on IO, but I've heard some have a terrible
> impact on IO.  It is just like how you can complete the same sort
> operation in seconds or hours depending on how dumb your sorting
> algorithm is.

I have an old OCZ which would increase IO latency to many seconds if not 
minutes whenever trim was running, to the point where users started 
complaining I had 'broken' their PC.  As if I would do such a thing.  LOL!  
Never mind trying to write anything, reading from the disk would take ages and 
the drive IO LED on the case stayed on for many minutes while TRIM was 
running.  I reformatted with btrfs, overprovisioned enough spare capacity and 
reduced the cron job for trim to once a month, which stopped them complaining.  
I don't know if the firmware was trying to write zeros to the drive 
deterministically, instead of just de-allocating the trimmed blocks.


> In any case, to really take advantage of SMR the OS needs to
> understand exactly how to structure its writes so as to not take a
> penalty, and that requires information about the implementation of the
> storage that isn't visible in a DM-SMR.  

Yes, I think all the OS can do is seek to minimise random writes and from what 
I read a SMR-friendlier fs will try to do this.


> Sure, some designs will do
> better on SMR even without this information, but I don't think they'll
> ever be all that efficient.  It is no different from putting f2fs on a
> flash drive with a brain-dead discard implementation - even if the OS
> does all its discards in nice consolidated contiguous operations it
> doesn't mean that the drive will handle that in milliseconds instead
> of just blocking all IO for an hour - sure, the drive COULD do the
> operation quickly, but that doesn't mean that the firmware designers
> didn't just ignore the simplest use case in favor of just optimizing
> around the assumption that NTFS is the only filesystem in the world.

For all I know consumer grade USB sticks with their cheap controller chips use 
no wear levelling at all:

https://support-en.sandisk.com/app/answers/detailweb/a_id/25185/~/learn-about-trim-support-for-usb-flash%2C-memory-cards%2C-and-ssd-on-windows-and

Consequently, all flash friendly fs can do is perhaps compress and write in 
batched mode to minimise write ops.

I can see where an SMR drive would be a suitable solution for storing media 
files, but I don't know if the shingled bands would cause leakage due to their 
proximity and eventually start losing data.  I haven't seen any reliability 
reports on this technology.

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

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

[Rich Freeman]

On Sat, Nov 16, 2024 at 2:47 PM Michael <confabulate@kintzios.com> wrote:
>
> As I understand it from reading various articles, the constraint of having to
> write sequentially a whole band when a random block changes within a band
> works the same on both HM-SMR and the more common DM-SMR.

Correct.

> What differs with
> HM-SMR instructions is the host is meant to take over the management of random
> writes and submit these as sequential whole band streams to the drive to be
> committed without a read-modify-write penalty.  I suppose for the host to have
> to read the whole band first from the drive, modify it and then submit it to
> the drive to write it as a whole band will be faster than letting the drive
> manage this operation internally and getting its internal cache full.

I doubt this would be any faster with a host-managed drive.  The same
pattern of writes is going to incur the same penalties.

The idea of a host-managed drive is to avoid the random writes in the
first place, and the need to do the random reads.  For this to work
the host has to know where the boundaries of the various regions are
and where it is safe to begin writes in each region.

Sure, a host could just use software to make the host-managed drive
behave the same as a drive-managed drive, but there isn't much benefit
there.  You'd want to use a log-based storage system/etc to just avoid
the random writes entirely.  You might not even want to use a POSIX
filesystem on it.

> This
> will not absolve the drive firmware from having to manage its own trim
> operations and the impact metadata changes could have on the drive, but some
> timing optimisation is perhaps reasonable.

Why would a host-managed SMR drive have ANY trim operations?  What
does trimming even mean on a host-managed drive?

Trimming is the act of telling the drive that it is safe to delete a
block without preserving it.  A host-managed drive shouldn't need to
be concerned with preserving any data during a write operation.  If it
is told to write something, it will just overwrite the data in the
subsequent overlapping cylinders.

Trimming is helpful with drive-managed SMR because if the drive isn't
told to trim a block that is about to be overwritten due to a write to
a different block, then the drive needs to first read, and then
rewrite the block.  Trimming tells the drive that this step can be
skipped, assuming ALL the blocks in that region have been trimmed.

> I don't know if SMRs use flash to record their STL status and data allocation
> between their persistent cache and shingled storage space.  I would think yes,
> or at least they ought to.  Without metadata written to different media, for
> such a small random write to take place atomically a whole SMR band will be
> read, modified in memory, written to a new temporary location and finally
> overwrite the original SMR band.

Well, drive-managed SMR drives typically have CMR regions for data
caching, and they could also be used to store the bitmap.  Cheap
drives might not support trim at all, and would just preserve all data
on write.  After all, it isn't performance that is driving the
decision to sneak SMR into consumer drives.  Flash would be the most
sensible way to do it though.

-- 
Rich

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

[Wol]

On 16/11/2024 20:13, Rich Freeman wrote:
> Well, drive-managed SMR drives typically have CMR regions for data
> caching, and they could also be used to store the bitmap.  Cheap
> drives might not support trim at all, and would just preserve all data
> on write.  After all, it isn't performance that is driving the
> decision to sneak SMR into consumer drives.  Flash would be the most
> sensible way to do it though.

I would have thought the best way for a host-managed drive to avoid 
masses of read-write would simply be to stream the data (files) to an 
SMR region, and the metadata (directory structure) to SMR.

That way, if you store the block list in the directory, you just drop 
data blocks, and if you keep track of which directory contents are 
stored in which SMR block, you can simply recover the space by copying 
the directory(ies) to a new block.

Cheers,
Wol

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

[Michael]

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

On Saturday 16 November 2024 20:13:30 GMT Rich Freeman wrote:
> On Sat, Nov 16, 2024 at 2:47 PM Michael <confabulate@kintzios.com> wrote:

> > What differs with
> > HM-SMR instructions is the host is meant to take over the management of
> > random writes and submit these as sequential whole band streams to the
> > drive to be committed without a read-modify-write penalty.  I suppose for
> > the host to have to read the whole band first from the drive, modify it
> > and then submit it to the drive to write it as a whole band will be
> > faster than letting the drive manage this operation internally and
> > getting its internal cache full.
> 
> I doubt this would be any faster with a host-managed drive.  The same
> pattern of writes is going to incur the same penalties.
> 
> The idea of a host-managed drive is to avoid the random writes in the
> first place, and the need to do the random reads.  For this to work
> the host has to know where the boundaries of the various regions are
> and where it is safe to begin writes in each region.

The random reads do not incur a time penalty, it is the R-M-W ops that cost 
time.  The host don't need to know where bands start and finish, only needs to 
submit data in whole sequential streams, so they can be written directly to 
the disk as in a CMR.  As long as data and metadata are submitted and written 
directly, the SMR would be alike a CMR in terms of its performance.


> Sure, a host could just use software to make the host-managed drive
> behave the same as a drive-managed drive, but there isn't much benefit
> there.  You'd want to use a log-based storage system/etc to just avoid
> the random writes entirely.  You might not even want to use a POSIX
> filesystem on it.
> 
> > This
> > will not absolve the drive firmware from having to manage its own trim
> > operations and the impact metadata changes could have on the drive, but
> > some timing optimisation is perhaps reasonable.
> 
> Why would a host-managed SMR drive have ANY trim operations?  What
> does trimming even mean on a host-managed drive?
> 
> Trimming is the act of telling the drive that it is safe to delete a
> block without preserving it.  A host-managed drive shouldn't need to
> be concerned with preserving any data during a write operation.  If it
> is told to write something, it will just overwrite the data in the
> subsequent overlapping cylinders.

I assumed, may be wrongly, there is still an STL function performed by the 
controller on HM-SMRs, to de-allocate deleted data bands whenever files are 
deleted, perform secure data deletions via its firmware, etc.  However, I can 
see if this is managed at the fs journal layer the drive controller could be 
dumb in this respect.  Perhaps what I had read referred to HM-SMR 'aware' 
drives, which may behave as DM-SMRs depending on the OS capability.

It would be interesting to see how different fs types perform on DM-SMRs.  
Looking at used drives on ebay they are rather still rather pricey for me to 
splash out on one of them, but since my PVR 14 year old WD SATA 2 refuses to 
die they may get cheaper by the time I need a replacement.

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

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

[Rich Freeman]

On Sun, Nov 17, 2024 at 6:22 AM Michael <confabulate@kintzios.com> wrote:
>
> On Saturday 16 November 2024 20:13:30 GMT Rich Freeman wrote:
> >
> > The idea of a host-managed drive is to avoid the random writes in the
> > first place, and the need to do the random reads.  For this to work
> > the host has to know where the boundaries of the various regions are
> > and where it is safe to begin writes in each region.
>
> The random reads do not incur a time penalty, it is the R-M-W ops that cost
> time.

We're saying the same thing.  If you don't preserve data that you
overwrite, then there is no need to read anything.  Random reads are
the same speed on CMR and SMR, but not doing a read is faster than
doing a read on either platform, and any read on an HDD is very slow.

> The host don't need to know where bands start and finish, only needs to
> submit data in whole sequential streams, so they can be written directly to
> the disk as in a CMR.  As long as data and metadata are submitted and written
> directly, the SMR would be alike a CMR in terms of its performance.

Again, we're saying the same thing, but making different assumptions
about how HM-SMR is implemented.

SMR can be appended to without penalty, just like tape.  In order to
append and not overwrite, the host needs to know where the boundaries
of the SMR domains are.

> I assumed, may be wrongly, there is still an STL function performed by the
> controller on HM-SMRs, to de-allocate deleted data bands whenever files are
> deleted, perform secure data deletions via its firmware, etc.  However, I can
> see if this is managed at the fs journal layer the drive controller could be
> dumb in this respect.

Honestly, I don't know exactly what commands an HM-SMR implements, and
since I doubt I'll ever use one, I can't really be bothered to look
them up.  The whole point of a HM-SMR drive is that the drive just
does exactly what the host does, and doesn't try to shield the host
from the details of how SMR works.  That's why they can be used
without performance penalties.  They're just very destructive to data
if they aren't used correctly.

> It would be interesting to see how different fs types perform on DM-SMRs.

Not that interesting, for me personally.  That's like asking how well
different filesystems would perform on tape.  If I'm storing data on
tape, I'll use an algorithm designed to work on tape, and a tape drive
that actually has a command set that doesn't try to pretend that it is
useful for random writes.  SMR is pretty analogous to tape, with the
benefit of being as fast as CMR for random reads.

If anything I've been trying to migrate away from HDD entirely.  NVMe
will always be more expensive I'm sure but the density and endurance
are continuing to improve, and of course the speed is incomparable.
Cost is only a few times more.  Biggest challenge is the lanes but
used workstations seem to be a way to get around that.

-- 
Rich

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

[Jack]

On 2024.11.17 16:26, Rich Freeman wrote:
> On Sun, Nov 17, 2024 at 6:22 AM Michael <confabulate@kintzios.com>  
> wrote:
> > On Saturday 16 November 2024 20:13:30 GMT Rich Freeman wrote:
[snip ....]
> > It would be interesting to see how different fs types perform on  
> DM-SMRs.
> 
> Not that interesting, for me personally.  That's like asking how well  
> different filesystems would perform on tape.  If I'm storing data on  
> tape, I'll use an algorithm designed to work on tape, and a tape  
> drive that actually has a command set that doesn't try to pretend  
> that it is useful for random writes.
What about DEC-Tape?  :-)  (https://en.wikipedia.org/wiki/DECtape)  (I  
may even have a few left in a closet somewhere, if only I could find  
someone to read them.)

> SMR is pretty analogous to tape, with the benefit of being as fast as  
> CMR for random reads.

[snip ....]

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

[Rich Freeman]

On Sun, Nov 17, 2024 at 6:04 PM Jack <ostroffjh@users.sourceforge.net> wrote:
>
> What about DEC-Tape?  :-)  (https://en.wikipedia.org/wiki/DECtape)  (I
> may even have a few left in a closet somewhere, if only I could find
> someone to read them.)
>

LTO is pretty much the only sensible choice these days as I understand
it.  I've looked into it for backup but you need to store a LOT of
data for it to make sense.  The issue is that the drives are just
super-expensive.  You can get much older generation drives used for
reasonable prices, but then the tapes have a very low capacity but
they aren't that cheap, so your cost per TB is pretty high, and of
course you have the inconvenience of long backup times and lots of
tape changes.  The newer generation drives are very reasonable in
terms of cost per TB, but the drives themselves cost thousands of
dollars.  Unless you're archiving hundreds of TB it is cheaper to just
buy lots of USB3 hard drives at $15/TB, and then you get the random IO
performance as a bonus.  The main downside to HDD at smaller scales is
that the drives themselves are more fragile, but that is mostly if
you're dropping them - in terms of storage conditions tape needs
better care than many appreciate for it to remain reliable.

For my offline onsite backups I just use a pair of USB3 drives on ZFS
right now.  For actual storage I'm trying to buy U.2 NVMe for future
expansion, but I don't have a pressing need for that until HDDs die or
I need more space.  Never makes sense to buy more than you need since
all this stuff gets cheaper with time...

-- 
Rich

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

[Matt Jolly]

Hi,
  > LTO is pretty much the only sensible choice these days as I understand
> it.

That's really the case, for bulk storage of any type you need to be able
to tier a lot of it offsite/offline. I'm responsible for a tape library
with a robot arm and about 13 drives raging from LTO7 through to LTO9.

> I've looked into it for backup but you need to store a LOT of
> data for it to make sense.  The issue is that the drives are just
> super-expensive.  You can get much older generation drives used for
> reasonable prices, but then the tapes have a very low capacity but
> they aren't that cheap, so your cost per TB is pretty high, and of
> course you have the inconvenience of long backup times and lots of
> tape changes.

The 7s are on their way out atm, so I'd expect to start seeing more pop
up for sale secondhand.

If you're doing tape though, 3:2:1 still applies, and you also (ideally)
want two different manufacturer drives writing to two different
manufacturer tapes to mitigate against issues like 'oh I got a firmware
update and my tape drive started writing garbage'.

> The newer generation drives are very reasonable in
> terms of cost per TB, but the drives themselves cost thousands of
> dollars.  Unless you're archiving hundreds of TB it is cheaper to just
> buy lots of USB3 hard drives at $15/TB, and then you get the random IO
> performance as a bonus.

... but you have to swap out hundreds of USB drives which, especially
on the cheap side, are likely to be significantly less robust than
tape carts over time.

> The main downside to HDD at smaller scales is
> that the drives themselves are more fragile, but that is mostly if
> you're dropping them - in terms of storage conditions tape needs
> better care than many appreciate for it to remain reliable.

It's really all downsides at the home scale. Your best bet is often
ensuring that you have an offsite (s3 + restic can be decent)
backup of your essential data and otherwise assuming that everything
else could be lost at any time and just not caring about it.

Anecdotally rsync (or s3...) to a cheap Hetzner VPS can be cost
effective for smaller datasets / backups. My 100T server at
home though? If it dies I lose everything non-critical on it!

Cheers,

Matt