Questions on the SSD plug-in

[Nerva]

My home server currently has a mix of 1TB, 2TB, 3TB, and 4TB drives, plus a 64 GB boot drive that is nearly full with Windows 7 crap, so I am about to swap it out for a 120 GB SSD, so there will be about 60 GB free on the boot drive.   I've also ordered a Seagate 8TB Archive HDD, and plan to order one or two more, once I know they will work with my server.   Of course, the issue with those drives is their goofy write behavior, and I have read that people recommend using the SSD plug-in to prioritize writing new files to the other drives, and then later the plug-in will move the files to the archive drive.

 

What I'm wondering is, whether I should use the 60 GB free on the SSD as the landing-zone for new files, or should I just use all the other non-archive HDD's?   I think this depends on details I don't understand regarding how the SSD plug-in actually works.

 

If I use the SSD, I would want that 60 GB free to be kept empty and only used for temporary storage until the files can be moved.   If I were to use the non-archive HDD's, I would want them to be about the same % full as the archive HDD's, write only to the non-archive HDD's and rebalance later.   Can the SSD plugin be used either way, or just one?

[Christopher (Drashna)]

The SSD Optimizer works by specifying "SSD" and "Archive" drives.  

 

It sets the "real time placement limiters" so that new files can only be placed on the drives marked as "SSDs".  (if there are no eligable drives, it will use other disks, but ONLY if there are no eligible drives). 

 

So files are placed on the "SSDs", and then later are balanced off of these drives and onto the drives marked as "Archive". 

 

 

I use "quotes" around the SSD and Archive terms, because these don't have to be SSD drives.  Yes, you could use your non SMR (Seagate Archive) drives as "SSD" drives.  Just keep in mind that it will attempt to clear out the content of these drivers. 

 

 

As for when this balancing occurs... that depends entirely on the main balancing settings. 

http://stablebit.com/Support/DrivePool/2.X/Manual?Section=Balancing%20Settings

 

 

I would recommend using several small disks (SSDs, or ~500GB HDDs) for the "SSD" drives.  

Regardless, the larger, the better. This is because these drives will be what is used to measure free space when adding content.  If you have small disks, and you copy a lot of data over, you may get warnings that you don't have enough space. 

 

Additionally, the duplication level you're using here is very important.  When you create files, all of the copies for duplication are created.  That means if your pool is 3x duplicated, it writes all three copies at once. This means that you'd need 3 "SSD" drives in this case. 

 

If you're not using duplication at all, then you should be fine.  Otherwise, if you want to use a single "SSD" with the pool and you do have duplication enabled... you can disable "Real Time Duplication" and that will work.  However, we highly recommend against it, as it means that there is up to a 24 hour delay for your files being duplicated. Also, files that are "in use" won't be duplicated until they're not longer in use. 

[Nerva]

Wait, so am I right in understanding that anything marked "SSD" will be kept entirely empty (only used for temporary writes)?   So if I were to mark one of my 4TB HDD's as "SSD" and the new 8TB Archive HDD as "Archive", DrivePool will try to keep the 4TB drive empty, so it is "ready" to write new files?

 

I do use duplication (indeed, the purpose of getting the 8TB SMR drives is to finally enable me to have 100% duplication), and I only have the one SSD (which will only have 60 GB or so free space), so am I right in thinking the thing to do is mark the 8TB SMR's as "archive", not bother to add the boot drive to the pool, and leave the non-SMR HDD's not marked either "SSD" or "Archive", so that DrivePool will only write to them, but then balance them equally with the SMR's?

[Christopher (Drashna)]

Yes.  The balancer will do it's best to keep the "SSD" drives completely empty. At least until the "Archive" drives are full past the specified limit. 

 

So using the 4TB drives as the "SSD" drives and the 8TB Seagate Archive (SMR) drives as the archive drives, this will place the new files on the 4TB drives, and then try to empty them. 

 

 

I do use duplication (indeed, the purpose of getting the 8TB SMR drives is to finally enable me to have 100% duplication), and I only have the one SSD (which will only have 60 GB or so free space), so am I right in thinking the thing to do is mark the 8TB SMR's as "archive", not bother to add the boot drive to the pool, and leave the non-SMR HDD's not marked either "SSD" or "Archive", so that DrivePool will only write to them, but then balance them equally with the SMR's?

 

Basically, yes.  

 

Though, to be honest, something that may be simpler here is to use the "Ordered File Placement" balancer to fill up the SMR drives, this way, they're not used for new drives ANYWAYS. (since they'll be full)

[Nerva]

Wait -- I installed the SSD plugin, and after adding the Seagate SMR drive to the pool, I wanted to set it to "Archive" and set the other HDD's in the pool to neither "SSD" nor "Archive", so that they are used for storage but are prioritized for new files rather than the Seagate SMR -- but the plugin will only let me toggle between SSD/Archive checkboxes -- I can't deselect both checkboxes at the same time.

 

Could the plugin be updated to allow neither SSD/Archive to be checked and thus effectively create a third type -- a "normal" HDD?

[Christopher (Drashna)]

Well, "Archive" is "normal", basically. 

 

New files are placed on the "SSD" drives and then moved off of it. Unfortunately, there isn't much more complexity than that. 

 

That said, if you really want to prioritize the drives, then use the "Ordered File Placement" option, but make sure that you set the option to "only prioritize new files.  This will fill up the rest of the drives in a sequential manner. 

 

 

Seagate SMR

 

To be blunt here, if you're not writing directly to these drives (eg, by using the SSD Optimizer), then there is no reason to de-prioritize these drives.  They're write performance may be atrocious, but I've seen the 190MB/s max sequential reads from these drives.  They get great read performance.

 

Though, I highly recommend formatting with 64kb "allocation unit size". This boosts performance a good chunk, helps prevent fragmentation, but you lose disk space on small files.  

ReFS uses this, by default, actually.

 

As for longevity, I have several of these drives that are more than a year old. No issues.  (other than a could of DOA drives).