SSD options

[JimPhreak]

So I've got 2 Intel 730 SSD's currently in a cache pool but the write speed to the BTRFS file system is just unacceptable and defeats the whole purpose of having a cache drive IMO.  So I'd like to pull one of the cache drives out and go back to a single cache drive with the XFS file system. 

 

Are SSD's still not supported as array devices?  And if not, any idea on when they might be?  I'd love to use the second SSD for my Downloads share so it doesn't take up the space on my cache drive.

[mr-hexen]

They work as array devices. I think it was Johnnie.black had a bunch he uses for testing the slow SAS2LP issue.

[JonathanM]

They work as array devices. I think it was Johnnie.black had a bunch he uses for testing the slow SAS2LP issue.

They work for normal read and write use, the question that has yet to be resolved that I have seen is if areas of the filesystem that are trimmed are still accurate for use in rebuilding other disks. I've only got a vague understanding of what is involved, but I think the issue is that if a SSD aware file system tells the drive that a certain area on the drive is no longer needed because the file(s) there have been deleted, the drive could possibly alter data that may be needed to reconstruct other drives.

 

Hopefully dual parity can be used to flesh out whether or not it's an issue, because we can use 1 SSD in the array and still not torpedo a recovery.

 

I could be way off base, I haven't seen anything about the issue in a while, so it may be a non-issue.

[rhinoman]

I don't know the answer but i'm also interested if I could use an SSD as my data store drive on the array as opposed the to metal spinners for long term storage. Benefits being no spin up and less write lag without using the cache drive which is now becoming busy with other jobs.

[JonathanM]

I would email Tom at limetech and ask whether he is comfortable with a SSD as an array member. Worst case wait for dual parity to get the bugs wrung out and then you could be more confident that even if the SSD returned bad data the array would still be able to rebuild a failed disk. As it is right now I'd want direct assurances from Tom before forging ahead.

[itimpi]

Is there any reason the downloads need to be parity protected?    If not the SSD could just be mounted outside the array (using the Unassigned Devices plugin).  This definitely works as lots of users have used this approach.

[JimPhreak]

Is there any reason the downloads need to be parity protected?    If not the SSD could just be mounted outside the array (using the Unassigned Devices plugin).  This definitely works as lots of users have used this approach.

It doesn't.  I haven't heard of this plugin... Is there a dedicated thread for it?

[itimpi]

Is there any reason the downloads need to be parity protected?    If not the SSD could just be mounted outside the array (using the Unassigned Devices plugin).  This definitely works as lots of users have used this approach.

It doesn't.  I haven't heard of this plugin... Is there a dedicated thread for it?

yes here.

 

Surprised you have not heard of this plugin - it is probably one of the more widely used ones.

[JimPhreak]

Is there any reason the downloads need to be parity protected?    If not the SSD could just be mounted outside the array (using the Unassigned Devices plugin).  This definitely works as lots of users have used this approach.

It doesn't.  I haven't heard of this plugin... Is there a dedicated thread for it?

yes here.

 

Surprised you have not heard of this plugin - it is probably one of the more widely used ones.

 

I shouldn't say I haven't heard of it as I've heard it mentioned on the threads.  Just never really looked into it since I didn't have a use case for it like I do now.

 

Thanks for the link.

[jonp]

Just wanted to chime in on this thread as mr-hexen sent me a PM asking me to do so.  The concerns brought up about cache pool performance are completely valid, and we have been experimenting with tweaking the OS to improve this.  I am pleased to report that in a recent test, a previous copy operation to the cache pool which seemed capped to ~60MB/s was able to exceed 250MB/s (unassigned SSD to cache pool copy operation).  We have further testing to go through at this point before we can fully implement in a stable release of unRAID, but it is our intention to do so.  We definitely agree that if writes to the cache are bottlenecked at < 2x of array performance, the benefit of the cache is highly negated.  As such, this is an important thing for us to get right.

[JimPhreak]

Just wanted to chime in on this thread as mr-hexen sent me a PM asking me to do so.  The concerns brought up about cache pool performance are completely valid, and we have been experimenting with tweaking the OS to improve this.  I am pleased to report that in a recent test, a previous copy operation to the cache pool which seemed capped to ~60MB/s was able to exceed 250MB/s (unassigned SSD to cache pool copy operation).  We have further testing to go through at this point before we can fully implement in a stable release of unRAID, but it is our intention to do so.  We definitely agree that if writes to the cache are bottlenecked at < 2x of array performance, the benefit of the cache is highly negated.  As such, this is an important thing for us to get right.

 

Thanks for posting that information jon, it's good to know this is being worked on.  If it's a fix that is of some priority maybe I will hold off on breaking my cache pool until you guys push out a beta for this so I can do some testing for you since I write to my cache pool a lot.

[jonp]

 

 

Just wanted to chime in on this thread as mr-hexen sent me a PM asking me to do so.  The concerns brought up about cache pool performance are completely valid, and we have been experimenting with tweaking the OS to improve this.  I am pleased to report that in a recent test, a previous copy operation to the cache pool which seemed capped to ~60MB/s was able to exceed 250MB/s (unassigned SSD to cache pool copy operation).  We have further testing to go through at this point before we can fully implement in a stable release of unRAID, but it is our intention to do so.  We definitely agree that if writes to the cache are bottlenecked at < 2x of array performance, the benefit of the cache is highly negated.  As such, this is an important thing for us to get right.

 

Thanks for posting that information jon, it's good to know this is being worked on.  If it's a fix that is of some priority maybe I will hold off on breaking my cache pool until you guys push out a beta for this so I can do some testing for you since I write to my cache pool a lot.

 

It is something I am hoping we can include in 6.2, but cannot confirm that at this point as we are still undergoing testing.

[rhinoman]

Jon, can you comment on the use of an SSD in the array please.

 

Do direct writes write to the SSD and then the parity caches the writes?

or does the parity bottleneck the write to an array SSD drive?

or should I leave this idea for now?

 

I'd like an ssd for my data (most written to array drive) and my music drive (for instant accessibility and almost zero lag) but will leave it for now if its a potential data loss issue.

[jonp]

Jon, can you comment on the use of an SSD in the array please.

 

Do direct writes write to the SSD and then the parity caches the writes?

or does the parity bottleneck the write to an array SSD drive?

or should I leave this idea for now?

 

I'd like an ssd for my data (most written to array drive) and my music drive (for instant accessibility and almost zero lag) but will leave it for now if its a potential data loss issue.

 

We don't officially support it yet as we need to some more testing on it but in theory, it should work just fine.  That said, your write performance will be bottlenecked because of the parity disk.  Read performance, however, should go full speed.