Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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 :-) :-)
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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 :-) :-)
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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
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 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 cov...@ccs.covici.com
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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 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
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
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
Michael wrote: > On Saturday, 23 May 2020 00:31:48 BST Rich Freeman wrote: >> On Fri, May 22, 2020 at 5:40 PM 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 ... >> 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 :-) :-)
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
On Saturday, 23 May 2020 00:31:48 BST Rich Freeman wrote: > On Fri, May 22, 2020 at 5:40 PM 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 ... > > 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? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
On Fri, May 22, 2020 at 5:40 PM 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 ... > 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
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
On Fri, May 22, 2020 at 2:08 PM antlists 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
On 22/05/2020 18:20, Rich Freeman wrote: On Fri, May 22, 2020 at 12:47 PM antlists 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
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
Rich Freeman wrote: > On Fri, May 22, 2020 at 12:15 PM Dale 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 :-) :-)
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
On Fri, May 22, 2020 at 12:47 PM antlists 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
On Fri, May 22, 2020 at 12:15 PM Dale 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
On 22/05/2020 16:43, Rich Freeman wrote: On Fri, May 22, 2020 at 11:32 AM Michael 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 wrote: > On Fri, May 22, 2020 at 11:32 AM Michael 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
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
On Fri, May 22, 2020 at 11:32 AM Michael 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
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/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
Rich Freeman wrote: > On Sun, May 10, 2020 at 2:11 PM Dale 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
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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
On Sun, May 10, 2020 at 2:11 PM Dale 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
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
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
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 >> >> :-) :-)
Re: [gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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 > > :-) :-) signature.asc Description: This is a digitally signed message part.
[gentoo-user] Seagate ST8000NM0065 PMR or SMR plus NAS SAS SATA question
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 :-) :-)
