Overclock.net › Forums › Components › Hard Drives & Storage › SSD › SSD RAID 0 setup
New Posts  All Forums:Forum Nav:

SSD RAID 0 setup - Page 2

post #11 of 14
Get one 256GB SSD now and add another down the road if you need it! tongue.gif

It really makes no difference except in a low percentage of instances where you are transfer large sums of data.

Since you are getting 2 128GB drives that is a better decision. Make sure you get drives that have good garbage collection as there is no RAID 0 TRIM support from what I know with AMD and Linux.

Also the difference b/w the AMD chipset and Intel's is mainly in benches. Unnoticeable real world.
post #12 of 14
Thread Starter 
Quote:
Originally Posted by Sean Webster View Post

Get one 256GB SSD now and add another down the road if you need it! tongue.gif

It really makes no difference except in a low percentage of instances where you are transfer large sums of data.

Since you are getting 2 128GB drives that is a better decision. Make sure you get drives that have good garbage collection as there is no RAID 0 TRIM support from what I know with AMD and Linux.

Also the difference b/w the AMD chipset and Intel's is mainly in benches. Unnoticeable real world.

I never really understood why TRIM hasn't really been RAID friendly, since, from what I can tell, it seems to be more of an OS feature than a chipset feature. That being said, Linux is actually the only OS that has TRIM support on all RAID chipsets it is compatible with, albeit through software (so it will take additional CPU cycles). I'm not sure if TRIM is supported for Windows on my chipset.

Worse case scenario, couldn't I run something like "cat /dev/zero > nullfile && rm nullfile" every once in a while to zero out every unused byte? The only problem is remembering to run that periodically and when I'm not in the middle of something.

As a side thought, BTRFS (another linux filesystem) is known to basically be the opposite of TRIM, where every time you save or overwrite a file, it will save the data in a separate location on the drive in order to keep a record of every file (until it runs out of space). It's actually pretty amazing because you can basically undo save states, as long as they're recent enough and haven't been overwritten. Anyways, the reason I'm bringing this up is if BTRFS is optimized for an anti-TRIM behavior, perhaps I could switch to it and I might not get the performance issues that I would otherwise need TRIM for. The strange thing is BTRFS actually has TRIM support, but this "logging" feature it has is optional AFAIK.
   
Gaming PC
(13 items)
 
CPUHard DriveOptical DriveOS
i3 4005U ADATA SP900 DVD-RW Arch Linux 
CPUMotherboardGraphicsRAM
Athlon 5350 GA-AM1M-S2H Integrated HD 8400 DDR3L 
Optical DriveCoolingOSPower
DVD-RW Mineral Oil Submersion Debian Jessie Generic 250W unit 
Case
A Home Made Aquarium 
CPUMotherboardGraphicsRAM
Ryzen 5 1500X Biostar X370GTN HIS IceQ R9 290 Gskill Ripjaws 
Hard DriveHard DriveCoolingOS
PNY SSD OCZ Vertex Asus Arctic Square Windows 10 + Arch Linux 
MonitorKeyboardPowerCase
32" Insignia 1080p TV Tesoro Durandal Seasonic SSR-650RM Thermaltake Core V1 
Audio
Realtek ALC892 
  hide details  
Reply
   
Gaming PC
(13 items)
 
CPUHard DriveOptical DriveOS
i3 4005U ADATA SP900 DVD-RW Arch Linux 
CPUMotherboardGraphicsRAM
Athlon 5350 GA-AM1M-S2H Integrated HD 8400 DDR3L 
Optical DriveCoolingOSPower
DVD-RW Mineral Oil Submersion Debian Jessie Generic 250W unit 
Case
A Home Made Aquarium 
CPUMotherboardGraphicsRAM
Ryzen 5 1500X Biostar X370GTN HIS IceQ R9 290 Gskill Ripjaws 
Hard DriveHard DriveCoolingOS
PNY SSD OCZ Vertex Asus Arctic Square Windows 10 + Arch Linux 
MonitorKeyboardPowerCase
32" Insignia 1080p TV Tesoro Durandal Seasonic SSR-650RM Thermaltake Core V1 
Audio
Realtek ALC892 
  hide details  
Reply
post #13 of 14
Worse case scenario, couldn't I run something like "cat /dev/zero > nullfile && rm nullfile" every once in a while to zero out every unused byte? The only problem is remembering to run that periodically and when I'm not in the middle of something.

Don't do that with a SSD, that is not what TRIM does at all! The NAND cells that contain bits can only be in two states, written to (contain data) and ready to be written to (erased.) The contents of a NAND cell does not determine if it contains data or is erased (in the erased state, if a cell was read, it contains a '1') since NAND can only be erased at the Block level. A flag bit is used to indicate a fully erased Block, or an in use Block with one or more pages written (even if it is not full of data.)

NAND must be erased before it can be written, it must be in the ready to be written to state. Current file systems designed for HDDs (which can simply over-write old data) don't tell a drive that data was deleted, it just puts the block addresses that were used by a "deleted" file into the free block list.

TRIM was created to cater to the necessities of NAND storage with file sysems written for HDDs. TRIM instructions contain the page/block addresses of deleted data. The SSD controller uses that information to erase no longer needed data, so the NAND storage can be in the ready to be written to state. It takes longer for a SSD controller to erase NAND and then write to it, than to simply write to it (already in the ready to write state.) Actually, erasing NAND is the slowest operation performed on it. If that can be done ahead of time (during a SSDs 'garbage collection" function) or on demand, the SSD will perform better.

That is why writing anything to NAND storage does not clear it, it really makes it worse. Even if you wrote '1', the default/erased state of a NAND bit, to the entire SSD, all the bits are in the written to state, and must be erased before being written to again.

TRIM is not simple to support in RAID arrays, since the OS/file system has no idea where the data is really stored on the RAID volume. The RAID software would need to translate what data can be erased according to TRIM, into how it is mapped in the RAID volume. Easier said than done!

Sean and others are steering you away from RAID volumes of multiple SSDs, because the high speeds seen in benchmarks of 1,000MB/s reads for example, is not how fast a SSD works all the time. That is for very large files only. Small 4K - 16K files, which are more common, and what make up a good percentage of an OS, are read at 20 - 35MB/s by SSDs (HDDs read less than 1MB/s on those files.) RAID 0 does not increase the small file read speeds at all, and usually decreases it, as seen in benchmarks.

OTOH, as a user of SSDs in RAID 0, IMO the benchmark programs are not telling the full story. IMO, RAID 0 volumes of SSDs can be faster than a single SSD. Not automatically, but they can be. FWIW, I have a RAID 0 volume of four 64GB Samsung SSDs, running as the OS volume, for over a year and it works fine.

AMD RAID faster than Intel RAID? Not from what I have seen...

Stressing the SATA ports? If it is designed with 10 ports, how does using half of them stress it? Maybe it does, but I'm an Intel user, with six ports max.
post #14 of 14
Thread Starter 
thanks a lot for the detailed post parsec i appreciate it.

But what I don't get is the difference between zeroing out a NAND vs eracing it. IIRC, the cells can only be in 2 states - 1 or 0. Correct me if im wrong but i gather that when the file is deleted, the actual contents of the file are left behind but the file name and inode are erased. So if the contents of the file are all that remains, why wouldn't zeroing out the entire drive make make the file considered erased?

I have considered getting a single 64GB drive for just OSes and programs and then the 2 128GB drives in RAID 0 for everything else, where I'd likely get the best performance in both situations.

Also, I meant to say my AMD chipset is faster in RAID than its intel COUNTERPART, I have absolutely no doubt that modern intel chips are better than AMD in both single drive and raid setups.
   
Gaming PC
(13 items)
 
CPUHard DriveOptical DriveOS
i3 4005U ADATA SP900 DVD-RW Arch Linux 
CPUMotherboardGraphicsRAM
Athlon 5350 GA-AM1M-S2H Integrated HD 8400 DDR3L 
Optical DriveCoolingOSPower
DVD-RW Mineral Oil Submersion Debian Jessie Generic 250W unit 
Case
A Home Made Aquarium 
CPUMotherboardGraphicsRAM
Ryzen 5 1500X Biostar X370GTN HIS IceQ R9 290 Gskill Ripjaws 
Hard DriveHard DriveCoolingOS
PNY SSD OCZ Vertex Asus Arctic Square Windows 10 + Arch Linux 
MonitorKeyboardPowerCase
32" Insignia 1080p TV Tesoro Durandal Seasonic SSR-650RM Thermaltake Core V1 
Audio
Realtek ALC892 
  hide details  
Reply
   
Gaming PC
(13 items)
 
CPUHard DriveOptical DriveOS
i3 4005U ADATA SP900 DVD-RW Arch Linux 
CPUMotherboardGraphicsRAM
Athlon 5350 GA-AM1M-S2H Integrated HD 8400 DDR3L 
Optical DriveCoolingOSPower
DVD-RW Mineral Oil Submersion Debian Jessie Generic 250W unit 
Case
A Home Made Aquarium 
CPUMotherboardGraphicsRAM
Ryzen 5 1500X Biostar X370GTN HIS IceQ R9 290 Gskill Ripjaws 
Hard DriveHard DriveCoolingOS
PNY SSD OCZ Vertex Asus Arctic Square Windows 10 + Arch Linux 
MonitorKeyboardPowerCase
32" Insignia 1080p TV Tesoro Durandal Seasonic SSR-650RM Thermaltake Core V1 
Audio
Realtek ALC892 
  hide details  
Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: SSD
Overclock.net › Forums › Components › Hard Drives & Storage › SSD › SSD RAID 0 setup