Simple Answer Dram-Less SSDs for Trunas

[tjrose91]

always thought you needed Dram SSDs for security reasons, i just want to add more pools to have extra copies of my data and plan to to purchase an redundant ATX PSU but those are pricey, if the Cache is handled by trunas then i dont think i need to worry about dram for ssd's unless i can get a good deal on them, 

 

OS - Trunas

CPU - G5420T

Ram - 4x4gb ddr4 2133mhz

 

 

[mariushm]

DRAM on ssd doesn't cache content... it's used to keep track of where files are stored in the memory chips.

[tjrose91]

2 minutes ago, mariushm said:

DRAM on ssd doesn't cache content... it's used to keep track of where files are stored in the memory chips.

thought that was the controller

[FlyingPotato_is_taken]

Should be fine.

 

If the mainboard support bifurcation  or has spare PCIE slots you could use dramless NVME drives instead of dramless SATA.

 

One more thing: Stay away from QLC. The price difference (for the consumer) is still not large enough to justify the downside: very slow speeds & latency, especilly if DRAM-less.

 

22 minutes ago, tjrose91 said:

always thought you needed Dram SSDs for security reasons,

No. There are SSD with capacitors that can safely flush the cache/DRAM to flash (datacentre/enterprise). This is called power loss protection.

The poor mans choice would be using a filesystem that is designed in such away that nothing will be damaged (what ever is currently written might be lost but the "old" file won't be damaged.

[tjrose91]

13 minutes ago, FlyingPotato_is_taken said:

Should be fine.

 

If the mainboard support bifurcation  or has spare PCIE slots you could use dramless NVME drives instead of dramless SATA.

 

One more thing: Stay away from QLC. The price difference (for the consumer) is still not large enough to justify the downside: very slow speeds & latency, especilly if DRAM-less.

 

No. There are SSD with capacitors that can safely flush the cache/DRAM to flash (datacentre/enterprise). This is called power loss protection.

The poor mans choice would be using a filesystem that is designed in such away that nothing will be damaged (what ever is currently written might be lost but the "old" file won't be damaged.

ahh, i mean its not like i will be constantly writing to them constantly, i might keep the 2.5 drive mechanical as the 5tb option is still cheap per drive from Seagate and with data recovery if needed and the NVME i found Teamgroup Gen3x4 4tb w/ Dram for less than 180 if on sale

[mariushm]

48 minutes ago, tjrose91 said:

thought that was the controller

To keep it simple ...

 

Data is arranged in sectors, of let's say 512 bytes or 4096 bytes. The smallest amount of data one can read or write is a sector, even when you open a 10 character text file in Notepad, the operating system will read a 512 byte sector from the drive. 

 

With mechanical drives, data is arranged as consecutive sectors in tracks on platters, and each track has a number of sectors on it, so when the operating system says give me the data at sector 1000, the hard drive knows it needs to look on the first platter, on the 2nd track, so it puts the read head there and then waits a rotation of the platter for the sector to come under the read/write head to read the data.

 

SSDs work differently. SSDs can't erase individual sectors, they can only erase big blocks of sectors. 

 

Data is arranged in blocks of let's say 24-64 MB of data, and these blocks have 512 or 4096 byte sectors.  After such block is erased, all sectors inside are available for writing stuff into them, but once stuff is written, it can not be overwritten until you erase the whole block. 

So the SSD controller keeps a table with information about the state of each sector  : can be written into it, has data  or can be erased. 

 

On the SSD the 10 character text file could located in some random flash memory chip, in a random block, in a random sector.  It's not a direct relationship between the sector number and the actual physical location.  For example, the table could contain this information initially : 

 

sector 1000 is in memory chip 2, block 10, sector 100,  flag = contains data 

 

So if the operating system requests sector 1000, the SSD controller can quickly look up the info in the table and access memory chip 2, block 10, sector 100 and read data from there. 

 

If you want to overwrite the contents with some stuff, the SSD controller has to do some things : locate a sector that can be written into, read the old sector, change the bytes as requested by the operating system, write this sector at the new location, mark old sector as "can be erased", and mark the new sector as "contains data" 

 

So the table would change to something like this : 

 

sector 1000 is in memory chip 5, block 1, sector 10,  flag = contains data   < where the changed data was written

sector 9999 is in memory chip 2, block 10, sector 100,  flag = can be erased  <- the old sector is marked as can be erased, and mapped to another random sector that has no data.

 

Once in a while, the SSD controller scans this table, and counts how many erased sectors are in a block, and if it's above some threshold, like let's say 30 MB out of 32 MB block are marked for erase, then the controller will find new locations for the remaining 2 MB, and erase the whole block to make it writable again.

 

So in DRAMless drives, this table is kept on the SSD, in a hidden portion of the flash memory kept in SLC mode, for higher endurance (like 50k+ erases vs 10k for MLC and less for TLC). With drives that use DRAM, the table is loaded into ram at startup, and periodically sections of this table that have changes are written to the SSD so that in case of power loss, the information is not lost.  On some drives that have no capacitors or batteries, every update is made both on dram and on the flash memory so that in case of power loss there's no desynchronization possible.

 

Basically, having dram basically means it makes it possible for the SSD controller to locate much faster where data is physically in the flash memory chips and much faster to locate empty areas of flash memory to put the data in, and that's why they fill slightly more responsive and have a bit higher read speeds. 

 

 

[Kilrah]

3 hours ago, tjrose91 said:

i just want to add more pools to have extra copies of my data

That's not a great data safety strategy, you want backup copies to be on another machine or offline external storage.

 

3 hours ago, tjrose91 said:

plan to to purchase an redundant ATX PSU

A UPS is more useful than that.

[tjrose91]

10 hours ago, mariushm said:

To keep it simple ...

 

Data is arranged in sectors, of let's say 512 bytes or 4096 bytes. The smallest amount of data one can read or write is a sector, even when you open a 10 character text file in Notepad, the operating system will read a 512 byte sector from the drive. 

 

With mechanical drives, data is arranged as consecutive sectors in tracks on platters, and each track has a number of sectors on it, so when the operating system says give me the data at sector 1000, the hard drive knows it needs to look on the first platter, on the 2nd track, so it puts the read head there and then waits a rotation of the platter for the sector to come under the read/write head to read the data.

 

SSDs work differently. SSDs can't erase individual sectors, they can only erase big blocks of sectors. 

 

Data is arranged in blocks of let's say 24-64 MB of data, and these blocks have 512 or 4096 byte sectors.  After such block is erased, all sectors inside are available for writing stuff into them, but once stuff is written, it can not be overwritten until you erase the whole block. 

So the SSD controller keeps a table with information about the state of each sector  : can be written into it, has data  or can be erased. 

 

On the SSD the 10 character text file could located in some random flash memory chip, in a random block, in a random sector.  It's not a direct relationship between the sector number and the actual physical location.  For example, the table could contain this information initially : 

 

sector 1000 is in memory chip 2, block 10, sector 100,  flag = contains data 

 

So if the operating system requests sector 1000, the SSD controller can quickly look up the info in the table and access memory chip 2, block 10, sector 100 and read data from there. 

 

If you want to overwrite the contents with some stuff, the SSD controller has to do some things : locate a sector that can be written into, read the old sector, change the bytes as requested by the operating system, write this sector at the new location, mark old sector as "can be erased", and mark the new sector as "contains data" 

 

So the table would change to something like this : 

 

sector 1000 is in memory chip 5, block 1, sector 10,  flag = contains data   < where the changed data was written

sector 9999 is in memory chip 2, block 10, sector 100,  flag = can be erased  <- the old sector is marked as can be erased, and mapped to another random sector that has no data.

 

Once in a while, the SSD controller scans this table, and counts how many erased sectors are in a block, and if it's above some threshold, like let's say 30 MB out of 32 MB block are marked for erase, then the controller will find new locations for the remaining 2 MB, and erase the whole block to make it writable again.

 

So in DRAMless drives, this table is kept on the SSD, in a hidden portion of the flash memory kept in SLC mode, for higher endurance (like 50k+ erases vs 10k for MLC and less for TLC). With drives that use DRAM, the table is loaded into ram at startup, and periodically sections of this table that have changes are written to the SSD so that in case of power loss, the information is not lost.  On some drives that have no capacitors or batteries, every update is made both on dram and on the flash memory so that in case of power loss there's no desynchronization possible.

 

Basically, having dram basically means it makes it possible for the SSD controller to locate much faster where data is physically in the flash memory chips and much faster to locate empty areas of flash memory to put the data in, and that's why they fill slightly more responsive and have a bit higher read speeds. 

 

 

So in a NAS where speed may not be an issue DRAM is a nice have than a must have

[tjrose91]

8 hours ago, Kilrah said:

That's not a great data safety strategy, you want backup copies to be on another machine or offline external storage.

 

A UPS is more useful than that.

have one copy on my Main gaming PC 3x4tb NVME soon gonna add an 2x2tb NVME for Steam, the NAS has a copy and a 10tb Cold Copy, a UPS would be needed as it would i hope have built in surge protection