[gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

Howdy,

I found a deal.  It's open box but it's a good price.  I've googled to
try to find out if it is PMR or SMR but I can't find anything that says
one way or another.  I did find where it says it has a sustained
throughput of 249MB/Sec which makes me think it is PMR, plus it is a
NAS/SAS drive.  Does anyone know for sure if it is a PMR drive?  It's a
good price at $150 but I'd like to avoid a SMR drive if at all possible. 

Also, I looked at the connector and it looks like a regular SATA
connector for the data and power.  However, it does say it is a SAS
drive.  I thought SAS had a different connector but maybe I'm wrong
about that.  These SAS drives will connect to a regular SATA connector
right?  I'm thinking it will but don't need a $150 doorstop.  :/ 

Thanks to anyone who can share some info.  Let's hope that drive isn't
gone before I can find out if it works or not. 

Dale

:-)  :-) 

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Michael]

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

According to this URL this drive claims to use perpendicular recording, so it 
is probably a PMR drive.

https://www.disctech.com/Seagate-ST8000NM0045-8TB-SATA-Hard-Drive

This finding is reinforced in this URL:

https://www.disctech.com/Seagate-ST8000NM0045-8TB-SATA-Hard-Drive



On Sunday, 10 May 2020 07:54:38 BST Dale wrote:
> Howdy,
> 
> I found a deal.  It's open box but it's a good price.  I've googled to
> try to find out if it is PMR or SMR but I can't find anything that says
> one way or another.  I did find where it says it has a sustained
> throughput of 249MB/Sec which makes me think it is PMR, plus it is a
> NAS/SAS drive.  Does anyone know for sure if it is a PMR drive?  It's a
> good price at $150 but I'd like to avoid a SMR drive if at all possible. 
> 
> Also, I looked at the connector and it looks like a regular SATA
> connector for the data and power.  However, it does say it is a SAS
> drive.  I thought SAS had a different connector but maybe I'm wrong
> about that.  These SAS drives will connect to a regular SATA connector
> right?  I'm thinking it will but don't need a $150 doorstop.  :/ 
> 
> Thanks to anyone who can share some info.  Let's hope that drive isn't
> gone before I can find out if it works or not. 
> 
> Dale
> 
> :-)  :-) 


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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

Hi Michael,

I think it is too.  Your link shows about what the link I was looking at
does. 

I did research the SATA and SAS connector issue again.  Seagate has a
picture of both for comparison and the drive I was looking at is a SAS
drive.  When I did more research, it seems you can connect a SATA drive
to SAS but not a SAS drive to SATA, unless that has changed since the
site I found posted about it.  Either way, while it does seem to be PMR,
I don't want to chance it not working since it is a SAS drive.  I need
to weed out SAS type drives unless I want to buy a SAS drive controller
card as well, to be certain it will work.  For those curious, this is a
link that shows a picture.  One has to look closely because at a glance,
they look a LOT alike. 

https://www.seagate.com/support/kb/connecting-sata-drive-to-sas-controller-006170en/


SATA drives may be plugged into SAS controllers.

SAS drives cannot be plugged into SATA controllers.


Back to digging and waiting for a good deal. 

Thanks much for the help.  :-D

Dale

:-)  :-) 



Michael wrote:
> According to this URL this drive claims to use perpendicular recording, so it 
> is probably a PMR drive.
>
> https://www.disctech.com/Seagate-ST8000NM0045-8TB-SATA-Hard-Drive
>
> This finding is reinforced in this URL:
>
> https://www.disctech.com/Seagate-ST8000NM0045-8TB-SATA-Hard-Drive
>
>
>
> On Sunday, 10 May 2020 07:54:38 BST Dale wrote:
>> Howdy,
>>
>> I found a deal.  It's open box but it's a good price.  I've googled to
>> try to find out if it is PMR or SMR but I can't find anything that says
>> one way or another.  I did find where it says it has a sustained
>> throughput of 249MB/Sec which makes me think it is PMR, plus it is a
>> NAS/SAS drive.  Does anyone know for sure if it is a PMR drive?  It's a
>> good price at $150 but I'd like to avoid a SMR drive if at all possible. 
>>
>> Also, I looked at the connector and it looks like a regular SATA
>> connector for the data and power.  However, it does say it is a SAS
>> drive.  I thought SAS had a different connector but maybe I'm wrong
>> about that.  These SAS drives will connect to a regular SATA connector
>> right?  I'm thinking it will but don't need a $150 doorstop.  :/ 
>>
>> Thanks to anyone who can share some info.  Let's hope that drive isn't
>> gone before I can find out if it works or not. 
>>
>> Dale
>>
>> :-)  :-) 


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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Daniel Frey]

On 5/10/20 1:02 AM, Dale wrote:
> Hi Michael,
> 
> I think it is too.  Your link shows about what the link I was looking at 
> does.
> 
> I did research the SATA and SAS connector issue again.  Seagate has a 
> picture of both for comparison and the drive I was looking at is a SAS 
> drive.  When I did more research, it seems you can connect a SATA drive 
> to SAS but not a SAS drive to SATA, unless that has changed since the 
> site I found posted about it.  Either way, while it does seem to be PMR, 
> I don't want to chance it not working since it is a SAS drive.  I need 
> to weed out SAS type drives unless I want to buy a SAS drive controller 
> card as well, to be certain it will work.  For those curious, this is a 
> link that shows a picture.  One has to look closely because at a glance, 
> they look a LOT alike.
> 
> https://www.seagate.com/support/kb/connecting-sata-drive-to-sas-controller-006170en/
> 
> 
> SATA drives may be plugged into SAS controllers.
> 
> SAS drives cannot be plugged into SATA controllers.
> 
> 
> Back to digging and waiting for a good deal.
> 
> Thanks much for the help.  :-D

That drive is a SAS drive and they use a generic photo of a hard drive - 
don't rely on those. That line of hard drives offer both SATA and SAS 
drives dependent on model.

They aren't compatible with SATA controllers.

And yes, SATA drives can be used on a SAS controller - I've been running 
that configuration on my file server for about 12 years.

Dan

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

Daniel Frey wrote:
> On 5/10/20 1:02 AM, Dale wrote:
>> Hi Michael,
>>
>> I think it is too.  Your link shows about what the link I was looking
>> at does.
>>
>> I did research the SATA and SAS connector issue again.  Seagate has a
>> picture of both for comparison and the drive I was looking at is a
>> SAS drive.  When I did more research, it seems you can connect a SATA
>> drive to SAS but not a SAS drive to SATA, unless that has changed
>> since the site I found posted about it.  Either way, while it does
>> seem to be PMR, I don't want to chance it not working since it is a
>> SAS drive.  I need to weed out SAS type drives unless I want to buy a
>> SAS drive controller card as well, to be certain it will work.  For
>> those curious, this is a link that shows a picture.  One has to look
>> closely because at a glance, they look a LOT alike.
>>
>> https://www.seagate.com/support/kb/connecting-sata-drive-to-sas-controller-006170en/
>>
>>
>>
>> SATA drives may be plugged into SAS controllers.
>>
>> SAS drives cannot be plugged into SATA controllers.
>>
>>
>> Back to digging and waiting for a good deal.
>>
>> Thanks much for the help.  :-D
>
> That drive is a SAS drive and they use a generic photo of a hard drive
> - don't rely on those. That line of hard drives offer both SATA and
> SAS drives dependent on model.
>
> They aren't compatible with SATA controllers.
>
> And yes, SATA drives can be used on a SAS controller - I've been
> running that configuration on my file server for about 12 years.
>
> Dan
>
>


The drive I found on ebay has a picture of the actual drive.  When I
found the difference, the link I posted, then I could see the drive is a
SAS.  The link I found explained that a SAS drive will not work with a
SATA port like I have.  It can work the other way around tho like you
have.  So, if I had a SAS controller, I could use SATA drives or SAS and
it work.  However, I have SATA controllers and can not hook up that SAS
drive.  They make a adapter and I found those on sale but I'm not
willing to spend $150 to see if it works.  It might, it might not. 
Either way, I get the difference between SATA and SAS now.  Different
connector but seems to be a much more durable drive. 

I thought I read a year or so ago the connectors was different but I
wasn't sure.  I thought maybe I misunderstood something or was just
wrong.  Turns out, it is different.  The one thing I wasn't sure at all
on, PMR or SMR.  It appeared to be PMR but I couldn't confirm it with
certainty.  It seems drive makers are being pretty deceptive on what
drives use. 

I did find a WD Red 8TB drive.  It costs a good bit more.  It's a good
deal but still costs more.  I'm going to keep looking.  Eventually I'll
either spend the money on the drive or find a really good deal.  My home
directory is at 69% so I got some time left.  Of course, my collection
is still growing. o_O

Thanks for the extra info. 

Dale

:-)  :-) 

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Rich Freeman]

On Sun, May 10, 2020 at 2:11 PM Dale <rdalek1967@gmail.com> wrote:
>
> I did find a WD Red 8TB drive.  It costs a good bit more.  It's a good
> deal but still costs more.  I'm going to keep looking.  Eventually I'll
> either spend the money on the drive or find a really good deal.  My home
> directory is at 69% so I got some time left.  Of course, my collection
> is still growing. o_O

In theory the 8TB reds are SMR-free.

You should take a look at /r/datahoarder and its wiki for tips on
cheap drives.  I've been shucking 10-12TB external drives lately.  You
can get a 12TB drive for $180 which is $15/TB.  It is REALLY hard to
top those sorts of prices in bare 3.5" drives of any kind.

The main problem with shucking is that it isn't the intended use of
the drive.  First you have to actually shuck them.  Then you get to
deal with the 3.3V pin issue depending on your power supply.  Then if
you ever want warranty replacement you need to restore the drive to
original condition.  And finally you have no guarantee as to what is
in the box, which means you have to follow various online sources like
that sub to see what others are seeing in these drives.  Indications
are that a lot of these drives are surplus enterprise drives of very
high quality - often having SMART data for Helium-filled drives.  But
for all we know next week they could start sticking SMR on them and
not tell anybody.

Depending on your use case you could probably even consider just
leaving these drives in their enclosures.  USB3 performs really well
in general, though obviously if you try to stack 8 drives on a single
USB3 bus you're probably not going to get the same performance as an
8x PCIe LSI HBA with 8 SATA ports.  If you're just using them for bulk
storage of multimedia that might not be a big deal, but if you're
trying to run a cluster of VMs off of them it could be a problem.

I think the drive manufacturers are basically trying to segment the
market.  They're selling essentially the same drive for either $180,
$220, or $320+ depending on whether you're willing to wait for a sale,
buy the external drive at full price, or you want the 3.5" drive
labeled for actual RAID use.  They know that small businesses without
volume deals will end up paying $320, and then enthusiasts will shuck
drives, and with any luck not bother asking for RMAs if they fail a
year later.  Large companies pay substantially lower prices for 3.5"
drives using volume discounts so they get the best of all worlds.

Oh, the other thing is that the larger external drives often have
semi-exclusive deals with stores like Best Buy.  They're becoming
easier to find, but usually you're going to end up with the best deals
waiting for a sale and getting them at a place like Best Buy, and not
your usual PC part dealer.  It is crazy, but that is how it works, and
it is a real bummer to go into Microcenter and see nothing but
overpriced low-capacity 3.5" drives (many of which ended up turning
out to be secretly SMR - not Microcenter's fault of course).
Ultimately this just reflects that drive manufacturers have
consolidated down into what amounts to a cartel with a lot of leverage
over anybody who isn't buying drives by the pallet.

-- 
Rich

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[antlists]

On 10/05/2020 20:11, Rich Freeman wrote:
>> I did find a WD Red 8TB drive.  It costs a good bit more.  It's a good
>> deal but still costs more.  I'm going to keep looking.  Eventually I'll
>> either spend the money on the drive or find a really good deal.  My home
>> directory is at 69% so I got some time left.  Of course, my collection
>> is still growing. o_O

> In theory the 8TB reds are SMR-free.

I thought I first found it on this list - wasn't it reported that the 
1TB and 8TB were still CMR but everything between was now SMR? Pretty 
naff since the SMR drives all refuse to add to a raid array, despite 
being advertised as "for NAS and RAID". Under UK law that would be a 
slam dunk RMA as "unfit for purpose".

Try the "Red Pro", which apparently are still all CMR. To the best of my 
knowledge the Seagate Ironwolves are still SMR-free, and there's also 
the Ironwolf Pros.

I've got two Ironwolves, but they're 2018-vintage. I think they're Red 
equivalents.

Cheers,
Wol

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Michael]

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

On Sunday, 10 May 2020 21:52:54 BST antlists wrote:
> On 10/05/2020 20:11, Rich Freeman wrote:
> >> I did find a WD Red 8TB drive.  It costs a good bit more.  It's a good
> >> deal but still costs more.  I'm going to keep looking.  Eventually I'll
> >> either spend the money on the drive or find a really good deal.  My home
> >> directory is at 69% so I got some time left.  Of course, my collection
> >> is still growing. o_O
> > 
> > In theory the 8TB reds are SMR-free.
> 
> I thought I first found it on this list - wasn't it reported that the
> 1TB and 8TB were still CMR but everything between was now SMR? Pretty
> naff since the SMR drives all refuse to add to a raid array, despite
> being advertised as "for NAS and RAID". Under UK law that would be a
> slam dunk RMA as "unfit for purpose".
> 
> Try the "Red Pro", which apparently are still all CMR. To the best of my
> knowledge the Seagate Ironwolves are still SMR-free, and there's also
> the Ironwolf Pros.
> 
> I've got two Ironwolves, but they're 2018-vintage. I think they're Red
> equivalents.
> 
> Cheers,
> Wol

An interesting article mentioning WD Red NAS drives which may actually be SMRs 
and how latency increases when cached writes need to be transferred into SMR 
blocks.

https://blocksandfiles.com/2020/04/15/shingled-drives-have-non-shingled-zones-for-caching-writes/


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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Rich Freeman]

On Fri, May 22, 2020 at 11:32 AM Michael <confabulate@kintzios.com> wrote:
>
> An interesting article mentioning WD Red NAS drives which may actually be SMRs
> and how latency increases when cached writes need to be transferred into SMR
> blocks.

Yeah, there is a lot of background on this stuff.

You should view a drive-managed SMR drive as basically a journaled
filesystem/database masquerading as a virtual drive.  One where the
keys/filenames are LBAs, and all the files are 512 bytes long.  :)

Really even most spinning drives are this way due to the 4k physical
sectors, but this is something much easier to deal with and handled by
the OS with aligned writes as much as possible.  SSDs have similar
issues but again the impact isn't nearly as bad and is more easily
managed by the OS with TRIM/etc.

A host-managed SMR drive operates much more like a physical drive, but
in this case the OS/application needs to be SMR-aware for performance
not to be absolutely terrible.

-- 
Rich

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

Rich Freeman wrote:
> On Fri, May 22, 2020 at 11:32 AM Michael <confabulate@kintzios.com> wrote:
>> An interesting article mentioning WD Red NAS drives which may actually be SMRs
>> and how latency increases when cached writes need to be transferred into SMR
>> blocks.
> Yeah, there is a lot of background on this stuff.
>
> You should view a drive-managed SMR drive as basically a journaled
> filesystem/database masquerading as a virtual drive.  One where the
> keys/filenames are LBAs, and all the files are 512 bytes long.  :)
>
> Really even most spinning drives are this way due to the 4k physical
> sectors, but this is something much easier to deal with and handled by
> the OS with aligned writes as much as possible.  SSDs have similar
> issues but again the impact isn't nearly as bad and is more easily
> managed by the OS with TRIM/etc.
>
> A host-managed SMR drive operates much more like a physical drive, but
> in this case the OS/application needs to be SMR-aware for performance
> not to be absolutely terrible.
>

The thing about the one I have now in use by LVM for /home, one is SMR
and one is PMR.  Even if the OS is aware, does it even know which drive
the data is going to end up being stored on?  I'm pretty sure since the
PMR drive was in use before the SMR that the PMR is likely full.  From
my understanding, LVM doesn't balance the data out. It will fill up a
drive and then move on to the next.  If you add another, it will fill up
the 2nd drive and then start on the newly added drive.  Maybe it does do
some magic but does the OS know which drive data is going to hit?

It seems to me that we could end up stuck with SMR or pay a premium for
PMR.  That's the part that worries me.  I'm not saying SMR isn't good
for a lot of folks but for us power type users, it matters.  You get
into servers and it matters a whole lot I'd imagine. 

Maybe I need to buy some drives before I can't even get them at a
affordable price at all???

Dale

:-)  :-) 

P. S. Thanks to Michael for the info.  I'll read it in a bit.  Having a
little sewer problem.  Dirty job.  -_o 

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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Rich Freeman]

On Fri, May 22, 2020 at 12:15 PM Dale <rdalek1967@gmail.com> wrote:
>
> The thing about the one I have now in use by LVM for /home, one is SMR and one is PMR.  Even if the OS is aware, does it even know which drive the data is going to end up being stored on?  I'm pretty sure since the PMR drive was in use before the SMR that the PMR is likely full.  From my understanding, LVM doesn't balance the data out. It will fill up a drive and then move on to the next.  If you add another, it will fill up the 2nd drive and then start on the newly added drive.  Maybe it does do some magic but does the OS know which drive data is going to hit?
>

So, as far as I'm aware nothing on linux is natively optimized for
SMR.  I'm sure some people use host-managed SMR drives on linux for
application-specific writing, but they're probably writing raw blocks
without using a filesystem.

However, if anything was going to be made SMR-aware then it would have
to be implemented at all block layers, just like barrier support.  I
think back in the early days of barrier support some layers didn't
support it, and a barrier can only make it from the filesystem to the
drive if it is implemented in lmv+mdadm+driver and so on.

If somebody added SMR support to ext4 but not to LVM then ext4
wouldn't detect the LV as an SMR drive, because lvm wouldn't pass that
through.

I suspect sooner or later a solution will emerge, but it could be a
while.  I suspect any solution would be for drives that could be set
to be host-managed, because otherwise you're working around an extra
layer of obfuscation.  Maybe you could have trim support without
further optimization, but that obviously isn't ideal.

-- 
Rich

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

Rich Freeman wrote:
> On Fri, May 22, 2020 at 12:15 PM Dale <rdalek1967@gmail.com> wrote:
>> The thing about the one I have now in use by LVM for /home, one is SMR and one is PMR.  Even if the OS is aware, does it even know which drive the data is going to end up being stored on?  I'm pretty sure since the PMR drive was in use before the SMR that the PMR is likely full.  From my understanding, LVM doesn't balance the data out. It will fill up a drive and then move on to the next.  If you add another, it will fill up the 2nd drive and then start on the newly added drive.  Maybe it does do some magic but does the OS know which drive data is going to hit?
>>
> So, as far as I'm aware nothing on linux is natively optimized for
> SMR.  I'm sure some people use host-managed SMR drives on linux for
> application-specific writing, but they're probably writing raw blocks
> without using a filesystem.
>
> However, if anything was going to be made SMR-aware then it would have
> to be implemented at all block layers, just like barrier support.  I
> think back in the early days of barrier support some layers didn't
> support it, and a barrier can only make it from the filesystem to the
> drive if it is implemented in lmv+mdadm+driver and so on.
>
> If somebody added SMR support to ext4 but not to LVM then ext4
> wouldn't detect the LV as an SMR drive, because lvm wouldn't pass that
> through.
>
> I suspect sooner or later a solution will emerge, but it could be a
> while.  I suspect any solution would be for drives that could be set
> to be host-managed, because otherwise you're working around an extra
> layer of obfuscation.  Maybe you could have trim support without
> further optimization, but that obviously isn't ideal.
>


That's why I want to avoid them if at all possible.  The best way to
know what I'm getting is to get what I know works best due to the fact
they been around for ages. 

To your point tho, it would likely take quite some effort to make every
layer aware of SMR.  Like you said, everything has to detect it and be
able to work with it or it fails and defaults to what we know slows
things down, to a crawl in some large write situations. 

I read some of the link that was posted.  I'm going to try to read it
again and hopefully finish it later, after I dig up and replace about a
100 feet of sewer line.  Tractor and really, REALLY, wet soil does not
go well for a sewer line only a few inches underground.  Gonna have to
go deeper and put some better fill in this time. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[antlists]

On 22/05/2020 16:43, Rich Freeman wrote:
> On Fri, May 22, 2020 at 11:32 AM Michael <confabulate@kintzios.com> wrote:
>>
>> An interesting article mentioning WD Red NAS drives which may actually be SMRs
>> and how latency increases when cached writes need to be transferred into SMR
>> blocks.
> 
> Yeah, there is a lot of background on this stuff.
> 
> You should view a drive-managed SMR drive as basically a journaled
> filesystem/database masquerading as a virtual drive.  One where the
> keys/filenames are LBAs, and all the files are 512 bytes long.  :)
> 
> Really even most spinning drives are this way due to the 4k physical
> sectors, but this is something much easier to deal with and handled by
> the OS with aligned writes as much as possible.  SSDs have similar
> issues but again the impact isn't nearly as bad and is more easily
> managed by the OS with TRIM/etc.
> 
> A host-managed SMR drive operates much more like a physical drive, but
> in this case the OS/application needs to be SMR-aware for performance
> not to be absolutely terrible.
> 
What puzzles me (or rather, it doesn't, it's just cost cutting), is why 
you need a *dedicated* cache zone anyway.

Stick a left-shift register between the LBA track and the hard drive, 
and by switching this on you write to tracks 2,4,6,8,10... and it's a 
CMR zone. Switch the register off and it's an SMR zone writing to all 
tracks.

The other thing is, why can't you just stream writes to a SMR zone, 
especially if we try and localise writes so lets say all LBAs in Gig 1 
go to the same zone ... okay - if we run out of zones to re-shingle to, 
then the drive is going to grind to a halt, but it will be much less 
likely to crash into that barrier in the first place.

Even better, if we have two independent heads, we could presumably 
stream updates using one head, and re-shingle with the other. But that's 
more cost ...

Cheers,
Wol

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Rich Freeman]

On Fri, May 22, 2020 at 12:47 PM antlists <antlists@youngman.org.uk> wrote:
>
> What puzzles me (or rather, it doesn't, it's just cost cutting), is why
> you need a *dedicated* cache zone anyway.
>
> Stick a left-shift register between the LBA track and the hard drive,
> and by switching this on you write to tracks 2,4,6,8,10... and it's a
> CMR zone. Switch the register off and it's an SMR zone writing to all
> tracks.

Disclaimer: I'm not a filesystem/DB design expert.

Well, I'm sure the zones aren't just 2 tracks wide, but that is worked
around easily enough.  I don't see what this gets you though.  If
you're doing sequential writes you can do them anywhere as long as
you're doing them sequentially within any particular SMR zone.  If
you're overwriting data then it doesn't matter how you've mapped them
with a static mapping like this, you're still going to end up with
writes landing in the middle of an SMR zone.

> The other thing is, why can't you just stream writes to a SMR zone,
> especially if we try and localise writes so lets say all LBAs in Gig 1
> go to the same zone ... okay - if we run out of zones to re-shingle to,
> then the drive is going to grind to a halt, but it will be much less
> likely to crash into that barrier in the first place.

I'm not 100% following you, but if you're suggesting remapping all
blocks so that all writes are always sequential, like some kind of
log-based filesystem, your biggest problem here is going to be
metadata.  Blocks logically are only 512 bytes, so there are a LOT of
them.  You can't just freely remap them all because then you're going
to end up with more metadata than data.

I'm sure they are doing something like that within the cache area,
which is fine for short bursts of writes, but at some point you need
to restructure that data so that blocks are contiguous or otherwise
following some kind of pattern so that you don't have to literally
remap every single block.  Now, they could still reside in different
locations, so maybe some sequential group of blocks are remapped, but
if you have a write to one block in the middle of a group you need to
still read/rewrite all those blocks somewhere.  Maybe you could use a
COW-like mechanism like zfs to reduce this somewhat, but you still
need to manage blocks in larger groups so that you don't have a ton of
metadata.

With host-managed SMR this is much less of a problem because the host
can use extents/etc to reduce the metadata, because the host already
needs to map all this stuff into larger structures like
files/records/etc.  The host is already trying to avoid having to
track individual blocks, so it is counterproductive to re-introduce
that problem at the block layer.

Really the simplest host-managed SMR solution is something like f2fs
or some other log-based filesystem that ensures all writes to the disk
are sequential.  Downside to flash-based filesystems is that they can
disregard fragmentation on flash, but you can't disregard that for an
SMR drive because random disk performance is terrible.

> Even better, if we have two independent heads, we could presumably
> stream updates using one head, and re-shingle with the other. But that's
> more cost ...

Well, sure, or if you're doing things host-managed then you stick the
journal on an SSD and then do the writes to the SMR drive
opportunistically.  You're basically describing a system where you
have independent drives for the journal and the data areas.  Adding an
extra head on a disk (or just having two disks) greatly improves
performance, especially if you're alternating between two regions
constantly.

-- 
Rich

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[antlists]

On 22/05/2020 18:20, Rich Freeman wrote:
> On Fri, May 22, 2020 at 12:47 PM antlists <antlists@youngman.org.uk> wrote:
>>
>> What puzzles me (or rather, it doesn't, it's just cost cutting), is why
>> you need a *dedicated* cache zone anyway.
>>
>> Stick a left-shift register between the LBA track and the hard drive,
>> and by switching this on you write to tracks 2,4,6,8,10... and it's a
>> CMR zone. Switch the register off and it's an SMR zone writing to all
>> tracks.
> 
> Disclaimer: I'm not a filesystem/DB design expert.
> 
> Well, I'm sure the zones aren't just 2 tracks wide, but that is worked
> around easily enough.  I don't see what this gets you though.  If
> you're doing sequential writes you can do them anywhere as long as
> you're doing them sequentially within any particular SMR zone.  If
> you're overwriting data then it doesn't matter how you've mapped them
> with a static mapping like this, you're still going to end up with
> writes landing in the middle of an SMR zone.

Let's assume each shingled track overwrites half the previous write. 
Let's also assume a shingled zone is 2GB in size. My method converts 
that into a 1GB CMR zone, because we're only writing to every second track.

I don't know how these drives cache their writes before re-organising, 
but this means that ANY disk zone can be used as cache, rather than 
having a (too small?) dedicated zone...

So what you could do is allocate one zone of CMR to every four or five 
zones of SMR and just reshingle each SMR as the CMR filled up. The 
important point is that zones can switch from CMR cache to SMR filling 
up, to full SMR zones decaying as they are re-written.
> 
>> The other thing is, why can't you just stream writes to a SMR zone,
>> especially if we try and localise writes so lets say all LBAs in Gig 1
>> go to the same zone ... okay - if we run out of zones to re-shingle to,
>> then the drive is going to grind to a halt, but it will be much less
>> likely to crash into that barrier in the first place.
> 
> I'm not 100% following you, but if you're suggesting remapping all
> blocks so that all writes are always sequential, like some kind of
> log-based filesystem, your biggest problem here is going to be
> metadata.  Blocks logically are only 512 bytes, so there are a LOT of
> them.  You can't just freely remap them all because then you're going
> to end up with more metadata than data.
> 
> I'm sure they are doing something like that within the cache area,
> which is fine for short bursts of writes, but at some point you need
> to restructure that data so that blocks are contiguous or otherwise
> following some kind of pattern so that you don't have to literally
> remap every single block. 

Which is why I'd break it down to maybe 2GB zones. If as the zone fills 
it streams, but is then re-organised and re-written properly when time 
permits, you've not got too large chunks of metadata. You need a btree 
to work out where each zone is stored, then each one has a btree to say 
where the blocks is stored. Oh - and these drives are probably 4K blocks 
only - most new drives are.

> Now, they could still reside in different
> locations, so maybe some sequential group of blocks are remapped, but
> if you have a write to one block in the middle of a group you need to
> still read/rewrite all those blocks somewhere.  Maybe you could use a
> COW-like mechanism like zfs to reduce this somewhat, but you still
> need to manage blocks in larger groups so that you don't have a ton of
> metadata.

The problem with drives at the moment is they run out of CMR cache, so 
they have to rewrite all those blocks WHILE THE USER IS STILL WRITING. 
The point of my idea is that they can repurpose disk as SMR or CMR as 
required, so they don't run out of cache at the wrong time ...

Yes metadata may bloom under pressure, but give the drives a break and 
they can grab a new zone, do an SMR ordered stream, and shrink the metadata.
> 
> With host-managed SMR this is much less of a problem because the host
> can use extents/etc to reduce the metadata, because the host already
> needs to map all this stuff into larger structures like
> files/records/etc.  The host is already trying to avoid having to
> track individual blocks, so it is counterproductive to re-introduce
> that problem at the block layer.
> 
> Really the simplest host-managed SMR solution is something like f2fs
> or some other log-based filesystem that ensures all writes to the disk
> are sequential.  Downside to flash-based filesystems is that they can
> disregard fragmentation on flash, but you can't disregard that for an
> SMR drive because random disk performance is terrible.

Which is why you have small(ish) zones so logically close writes are 
hopefully physically close as well ...
> 
>> Even better, if we have two independent heads, we could presumably
>> stream updates using one head, and re-shingle with the other. But that's
>> more cost ...
> 
> Well, sure, or if you're doing things host-managed then you stick the
> journal on an SSD and then do the writes to the SMR drive
> opportunistically.  You're basically describing a system where you
> have independent drives for the journal and the data areas.  Adding an
> extra head on a disk (or just having two disks) greatly improves
> performance, especially if you're alternating between two regions
> constantly.
> 
EXcept I'm describing a system where journal and data areas are 
interchangeable :-)

Cheers,
Wol

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Rich Freeman]

On Fri, May 22, 2020 at 2:08 PM antlists <antlists@youngman.org.uk> wrote:
>
> So what you could do is allocate one zone of CMR to every four or five
> zones of SMR and just reshingle each SMR as the CMR filled up. The
> important point is that zones can switch from CMR cache to SMR filling
> up, to full SMR zones decaying as they are re-written.

I get how this will provide more flexibility.  However, there is a big
problem here.  Unless you are using TRIM you have no idea what space
is in use vs free.  Once a block has been written to once, it needs to
be forever treated as occupied.

So this cache really is only useful when the drive is brand new.  Once
it has all been written once you're limited to dedicated CMR regions
for cache, because all the SMR areas are shingled.

If you are using TRIM then this does give you more flex space, but
only if enough overlapping space is unused, and you do need to
reshingle to write to that unused space.  Depending on the degree of
overlap you still have only a fraction of disk available for your
cache.

> Which is why I'd break it down to maybe 2GB zones. If as the zone fills
> it streams, but is then re-organised and re-written properly when time
> permits, you've not got too large chunks of metadata.
> ...
> The problem with drives at the moment is they run out of CMR cache, so
> they have to rewrite all those blocks WHILE THE USER IS STILL WRITING.
> The point of my idea is that they can repurpose disk as SMR or CMR as
> required, so they don't run out of cache at the wrong time ...

You still have a limited cache, and if it fills up you hit the performance wall.

The question just comes whether it is more efficient to have
flex-space that can be PMR or SMR, or having dedicated space that is
PMR-only.  I think that depends greatly on whether you can assume the
use of TRIM and how much free space the drive will have in general.
Since PMR is less dense you have to give up a lot of SMR space for any
PMR use of that space.

A big problem with drive-managed SMR is that it basically has to
assume the OS is dumb, which means most writes are in-place with no
trims, assuming the drive even supports trim.

-- 
Rich

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[antlists]

On 22/05/2020 19:23, Rich Freeman wrote:
> A big problem with drive-managed SMR is that it basically has to
> assume the OS is dumb, which means most writes are in-place with no
> trims, assuming the drive even supports trim.

I think the problem with the current WD Reds is, in part, that the ATA-4 
spec is required to support trim, but the ATA-3 spec is the current 
version. Whoops ...

So yes, even if the drive does support trim, it has no way of telling 
the OS that it does ...

Cheers,
Wol

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Rich Freeman]

On Fri, May 22, 2020 at 5:40 PM antlists <antlists@youngman.org.uk> wrote:
>
> On 22/05/2020 19:23, Rich Freeman wrote:
> > A big problem with drive-managed SMR is that it basically has to
> > assume the OS is dumb, which means most writes are in-place with no
> > trims, assuming the drive even supports trim.
>
> I think the problem with the current WD Reds is, in part, that the ATA-4
> spec is required to support trim, but the ATA-3 spec is the current
> version. Whoops ...
>

Probably was thought up by the same genius who added the 3.3V reset
pin to the SATA standard.

-- 
Rich

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Michael]

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

On Saturday, 23 May 2020 00:31:48 BST Rich Freeman wrote:
> On Fri, May 22, 2020 at 5:40 PM antlists <antlists@youngman.org.uk> wrote:
> > On 22/05/2020 19:23, Rich Freeman wrote:
> > > A big problem with drive-managed SMR is that it basically has to
> > > assume the OS is dumb, which means most writes are in-place with no
> > > trims, assuming the drive even supports trim.
> > 
> > I think the problem with the current WD Reds is, in part, that the ATA-4
> > spec is required to support trim, but the ATA-3 spec is the current
> > version. Whoops ...
> 
> Probably was thought up by the same genius who added the 3.3V reset
> pin to the SATA standard.

Is there a way to determine if a drive on sale is SMR *before* purchase?  I 
assume after purchase it is a matter of filling up the drive with zeros and 
keeping an eye on it stalling for minutes at a time; or is there some hdparm/
smartctl output to inform accordingly?

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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

Michael wrote:
> On Saturday, 23 May 2020 00:31:48 BST Rich Freeman wrote:
>> On Fri, May 22, 2020 at 5:40 PM antlists <antlists@youngman.org.uk> wrote:
>>> On 22/05/2020 19:23, Rich Freeman wrote:
>>>> A big problem with drive-managed SMR is that it basically has to
>>>> assume the OS is dumb, which means most writes are in-place with no
>>>> trims, assuming the drive even supports trim.
>>> I think the problem with the current WD Reds is, in part, that the ATA-4
>>> spec is required to support trim, but the ATA-3 spec is the current
>>> version. Whoops ...
>> Probably was thought up by the same genius who added the 3.3V reset
>> pin to the SATA standard.
> Is there a way to determine if a drive on sale is SMR *before* purchase?  I 
> assume after purchase it is a matter of filling up the drive with zeros and 
> keeping an eye on it stalling for minutes at a time; or is there some hdparm/
> smartctl output to inform accordingly?


I google the model number with the terms smr pmr and then see what it
provides.  Generally, you can tell which it is BUT one never knows if
they change something. 

What bothers me is the fact they don't disclose what a drive is. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Wols Lists]

On 23/05/20 08:39, Michael wrote:
> Is there a way to determine if a drive on sale is SMR *before* purchase?  I 
> assume after purchase it is a matter of filling up the drive with zeros and 
> keeping an eye on it stalling for minutes at a time; or is there some hdparm/
> smartctl output to inform accordingly?

THAT IS THE PROBLEM!

If you read up where people have been surprised, the information is
encoded in the last four letters of the drive model. In other words, the
bit that nobody looks at.

For example, I can't remember whether EFAX is CMR or SMR, but that is
what tells you on a WD Red. And even if you're lucky enough to be told
the drive model, that is the bit that is updated every time the model is
updated, and it's the bit they don't tell you, and it's the bit you only
discover when the drive is in your hands and you can read the
information plate on it and google it.

Cheers,
Wol

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[David Haller]

Hello,

On Sat, 23 May 2020, Michael wrote:
>On Saturday, 23 May 2020 00:31:48 BST Rich Freeman wrote:
>> On Fri, May 22, 2020 at 5:40 PM antlists <antlists@youngman.org.uk> wrote:
>> > On 22/05/2020 19:23, Rich Freeman wrote:
>> > > A big problem with drive-managed SMR is that it basically has to
>> > > assume the OS is dumb, which means most writes are in-place with no
>> > > trims, assuming the drive even supports trim.
>> > 
>> > I think the problem with the current WD Reds is, in part, that the ATA-4
>> > spec is required to support trim, but the ATA-3 spec is the current
>> > version. Whoops ...
>> 
>> Probably was thought up by the same genius who added the 3.3V reset
>> pin to the SATA standard.
>
>Is there a way to determine if a drive on sale is SMR *before*
>purchase?

WD Red WD*EFRX are PMR.
WD Red WD*EFAX are SMR (AFAIK, could be, that some are PMR).

ISTR, that the "Red Pro" are all PMR (so far).

HTH,
-dnh

-- 
If I wanted to point and drool, I'd go to a Chippendales show.
                                              -- Leigh Metcalf

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[John Covici]

On Sat, 23 May 2020 11:39:40 -0400,
David Haller wrote:
> 
> Hello,
> 
> On Sat, 23 May 2020, Michael wrote:
> >On Saturday, 23 May 2020 00:31:48 BST Rich Freeman wrote:
> >> On Fri, May 22, 2020 at 5:40 PM antlists <antlists@youngman.org.uk> wrote:
> >> > On 22/05/2020 19:23, Rich Freeman wrote:
> >> > > A big problem with drive-managed SMR is that it basically has to
> >> > > assume the OS is dumb, which means most writes are in-place with no
> >> > > trims, assuming the drive even supports trim.
> >> > 
> >> > I think the problem with the current WD Reds is, in part, that the ATA-4
> >> > spec is required to support trim, but the ATA-3 spec is the current
> >> > version. Whoops ...
> >> 
> >> Probably was thought up by the same genius who added the 3.3V reset
> >> pin to the SATA standard.
> >
> >Is there a way to determine if a drive on sale is SMR *before*
> >purchase?
> 
> WD Red WD*EFRX are PMR.
> WD Red WD*EFAX are SMR (AFAIK, could be, that some are PMR).
> 
> ISTR, that the "Red Pro" are all PMR (so far).

How about WD4001FFSX-68JNUN0? I hope its pmr.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici wb2una
         covici@ccs.covici.com

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[David Haller]

Hello,

On Sat, 23 May 2020, John Covici wrote:
>On Sat, 23 May 2020 11:39:40 -0400, David Haller wrote:
>> WD Red WD*EFRX are PMR.
>> WD Red WD*EFAX are SMR (AFAIK, could be, that some are PMR).
>> 
>> ISTR, that the "Red Pro" are all PMR (so far).
>
>How about WD4001FFSX-68JNUN0? I hope its pmr.

That's a "Red Pro" ...

-dnh

-- 
There are some people who clearly shouldn't be put in charge of
any office-equipment more technical than a blunt finger dipped
in water-soluble ink.                                -- Tanuki

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[David Haller]

Hello,

On Fri, 22 May 2020, antlists wrote:
>On 22/05/2020 19:23, Rich Freeman wrote:
>> A big problem with drive-managed SMR is that it basically has to
>> assume the OS is dumb, which means most writes are in-place with no
>> trims, assuming the drive even supports trim.
>
>I think the problem with the current WD Reds is, in part, that the ATA-4 spec
>is required to support trim, but the ATA-3 spec is the current version.
>Whoops ...

ATA-8 is the current spec. Though practically unused. The used spec is
ATA-7 in virtually all drives for IIRC the last 10ish years or so.

Did you mean SATA specs? Well, then there's only SATA-1 (1.5GBit/s),
SATA-2, (3.0GBit/s) and SATA-3 (6.0GBit/s), and of the latter SATA
revision 3.1 introduced TRIM[2]. Oh, and rev. 3.3 introduced some
extras for SMR [3].

HTH,
-dnh

[1] https://en.wikipedia.org/wiki/Parallel_ATA
[2] https://en.wikipedia.org/wiki/Serial_ATA#SATA_revision_3.0_(6_Gbit/s,_600_MB/s,_Serial_ATA-600)
[3] https://en.wikipedia.org/wiki/Serial_ATA#SATA_revision_3.3

-- 
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first.       (Arno Schaefer's .sig)

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

David Haller wrote:
> Hello,
>
> On Fri, 22 May 2020, antlists wrote:
>> On 22/05/2020 19:23, Rich Freeman wrote:
>>> A big problem with drive-managed SMR is that it basically has to
>>> assume the OS is dumb, which means most writes are in-place with no
>>> trims, assuming the drive even supports trim.
>> I think the problem with the current WD Reds is, in part, that the ATA-4 spec
>> is required to support trim, but the ATA-3 spec is the current version.
>> Whoops ...
> ATA-8 is the current spec. Though practically unused. The used spec is
> ATA-7 in virtually all drives for IIRC the last 10ish years or so.
>
> Did you mean SATA specs? Well, then there's only SATA-1 (1.5GBit/s),
> SATA-2, (3.0GBit/s) and SATA-3 (6.0GBit/s), and of the latter SATA
> revision 3.1 introduced TRIM[2]. Oh, and rev. 3.3 introduced some
> extras for SMR [3].
>
> HTH,
> -dnh
>
> [1] https://en.wikipedia.org/wiki/Parallel_ATA
> [2] https://en.wikipedia.org/wiki/Serial_ATA#SATA_revision_3.0_(6_Gbit/s,_600_MB/s,_Serial_ATA-600)
> [3] https://en.wikipedia.org/wiki/Serial_ATA#SATA_revision_3.3
>


Given the info in link 3, does that mean that OSs and their layers will
start adding options to help make SMR drives work better?  In other
words, file system support, LVM support if needed and maybe even
something that will make RAID setups work better?  From the way it
sounds, right now there is basically none of that.  Everything happens
on the drive and once it hits the limit of what it can handle, things
start screeching to a halt with the OS left in the dark about what is
going on exactly.  If SMR is going to be the new thing, it needs to work
better, RAID seems to really need that help. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

Rich Freeman wrote:
> On Sun, May 10, 2020 at 2:11 PM Dale <rdalek1967@gmail.com> wrote:
>> I did find a WD Red 8TB drive.  It costs a good bit more.  It's a good
>> deal but still costs more.  I'm going to keep looking.  Eventually I'll
>> either spend the money on the drive or find a really good deal.  My home
>> directory is at 69% so I got some time left.  Of course, my collection
>> is still growing. o_O
> In theory the 8TB reds are SMR-free.

That was my thinking.  It appears to be a highly durable drive.  These
color codes can sometimes be confusing since there is so many of them. 
It appears they are similar across makers tho.  Well, mostly.  I'm sure
there is some differences.  ;-)


>
> You should take a look at /r/datahoarder and its wiki for tips on
> cheap drives.  I've been shucking 10-12TB external drives lately.  You
> can get a 12TB drive for $180 which is $15/TB.  It is REALLY hard to
> top those sorts of prices in bare 3.5" drives of any kind.
>
> The main problem with shucking is that it isn't the intended use of
> the drive.  First you have to actually shuck them.  Then you get to
> deal with the 3.3V pin issue depending on your power supply.  Then if
> you ever want warranty replacement you need to restore the drive to
> original condition.  And finally you have no guarantee as to what is
> in the box, which means you have to follow various online sources like
> that sub to see what others are seeing in these drives.  Indications
> are that a lot of these drives are surplus enterprise drives of very
> high quality - often having SMART data for Helium-filled drives.  But
> for all we know next week they could start sticking SMR on them and
> not tell anybody.
>
> Depending on your use case you could probably even consider just
> leaving these drives in their enclosures.  USB3 performs really well
> in general, though obviously if you try to stack 8 drives on a single
> USB3 bus you're probably not going to get the same performance as an
> 8x PCIe LSI HBA with 8 SATA ports.  If you're just using them for bulk
> storage of multimedia that might not be a big deal, but if you're
> trying to run a cluster of VMs off of them it could be a problem.
>
> I think the drive manufacturers are basically trying to segment the
> market.  They're selling essentially the same drive for either $180,
> $220, or $320+ depending on whether you're willing to wait for a sale,
> buy the external drive at full price, or you want the 3.5" drive
> labeled for actual RAID use.  They know that small businesses without
> volume deals will end up paying $320, and then enthusiasts will shuck
> drives, and with any luck not bother asking for RMAs if they fail a
> year later.  Large companies pay substantially lower prices for 3.5"
> drives using volume discounts so they get the best of all worlds.
>
> Oh, the other thing is that the larger external drives often have
> semi-exclusive deals with stores like Best Buy.  They're becoming
> easier to find, but usually you're going to end up with the best deals
> waiting for a sale and getting them at a place like Best Buy, and not
> your usual PC part dealer.  It is crazy, but that is how it works, and
> it is a real bummer to go into Microcenter and see nothing but
> overpriced low-capacity 3.5" drives (many of which ended up turning
> out to be secretly SMR - not Microcenter's fault of course).
> Ultimately this just reflects that drive manufacturers have
> consolidated down into what amounts to a cartel with a lot of leverage
> over anybody who isn't buying drives by the pallet.
>


I've read about doing that before and you are right, you can save some
bucks but you may not get what you want every time.  Most likely you
will but the risk is there.  Then there's the warranty deal as well. 
The 3.3v thing, I think they sell adapters for that now.  That said, you
do get a decent enclosure and those aren't cheap either, good ones
anyway.  I like fans on mine.

What I'm doing is replacing a 6TB SMR drive that is part of /home.  I
think you helped discover that in a previous thread a while back.  Right
now /home is a 6TB and a 3TB drive with LVM.  I plan to replace the 6
with a 8 which will give me a PMR drive and 2TBs of additional space. 
Later on I'll replace the 3TB with either a 6 or another 8TB drive. 
That should hold me a while.  That's either 14TBs or 16TBs.  That's a
lot of videos and such.

I check in several places but am not opposed to buying from someone a
open box or a drive pulled from a machine but barely or even not used at
all if the person is willing to stand behind it while I test it or
selling those types of things is their business.  It's a bit of a
judgment call.  Price affects it too. New would be great but deals on
those aren't as often. 

Still keeping a eye out for a deal tho.  Most are pushing $200 pretty
hard.  I just bought a new window A/C so gotta pay off that card,
again.  It was on sale plus free shipping.  Plus, I still want speakers
for my TV.  Computer speakers are doing really well.  They are a lot
better than those store bought things. 

Dale

:-)  :-) 

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

Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question

[Dale]

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

Dale wrote:
> Howdy,
>
> I found a deal.  It's open box but it's a good price.  I've googled to
> try to find out if it is PMR or SMR but I can't find anything that says
> one way or another.  I did find where it says it has a sustained
> throughput of 249MB/Sec which makes me think it is PMR, plus it is a
> NAS/SAS drive.  Does anyone know for sure if it is a PMR drive?  It's a
> good price at $150 but I'd like to avoid a SMR drive if at all possible. 
>
> Also, I looked at the connector and it looks like a regular SATA
> connector for the data and power.  However, it does say it is a SAS
> drive.  I thought SAS had a different connector but maybe I'm wrong
> about that.  These SAS drives will connect to a regular SATA connector
> right?  I'm thinking it will but don't need a $150 doorstop.  :/ 
>
> Thanks to anyone who can share some info.  Let's hope that drive isn't
> gone before I can find out if it works or not. 
>
> Dale
>
> :-)  :-) 
>


I missed out on previous deal.  I have ran up on a few sites that list
PMR and SMR drives.  One site is a look up just to find out if it is SMR
or PMR.  I'm not sure how accurate any of these are but it is likely
better than nothing.  I did want to share these links just in case they
may be helpful to someone else.

https://issmrdrive.com/

https://www.ixsystems.com/community/resources/list-of-known-smr-drives.141/

This next one is Chinese I think.  Thing is, the part that is needed is
English, for us English only speakers. 

https://www.jianshu.com/p/51bc72e29138

I hope some of you will bookmark these and find them useful later on.  I
sure do get a lot of help from the folks here.  If anyone else has links
like these, it would be nice to share.  Now to go figure out how to tell
if a used drive is "shucked" or not.  I don't want to buy one and run
into that 3.3V pin problem.  Youtube is waiting.

Dale

:-)  :-) 

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