i’m looking to replace my mom’s spinning rust with some SSD instead. But ever since she lost all her data with bitlocker, she’s not willing to save anything on the computer SSD. Instead, she needs to save all her working files in a USB external drive instead. (and i’m not gonna argue against whatever logic she thinks of)
SSD with RAM is more expensive than i thought, and all the cheaper ones usd host memory buffer. Obviously, this doesn’t work over USB, and i see some forum posts says that a lack of RAM on those drives will run down the write endurance, which will be a pain in my end.
But in reality, how much of a difference it makes? If it does, what do you recommend as the cheapest option? if it doesn’t make a difference, then shall i just go with the solidigm p41?
First the right hand rule: SSD inside a computer running on reasonably modern NVMe/PCIExpress does not require dedicated RAM module for caching. It will use enough RAM to compensate.
Moving it to external drives the RAM is not required either as Windows caching is enabled by default. Not as good as letting the drive use it, but the size and amount is enough for a regular user.
Interface is where it gets tricky - my experience with NVMe on USB is poor. Getting a discounted 2.5" SATA would be my choice.
As for the whole concept - you can help her by setting up sync or SnapRAID so the internal SSD is secondary backup. Especially with parents on windows SyncTrayzor and a SyncThing instance on my server has been great. Better if they use Android and/or tablet.
The RAM inside SSDs *mostly handles the NAND’s FTL as opposed to caching data transfers (but does do some of the later).
The FTL is changing often and when a SSD doesn’t have DRAM to store it in the SSD is forced to put the FTL into NAND and it wears that NAND out more quickly; even then I wouldn’t be too worried about wearing out the SSD, they still have pretty good endurance ratings even without DRAM.
HMB might work over USB depending on how the bus is implemented, but it sounds kind of janky to me.
What I’d be most concerned about with the SSD is cell charge decay. Very very few SSDs do anything to prevent this from happening and data on the SSD will become stale after a year give or take and become hard to read, slowing the SSD down substantially.
That is a very good point, I got an impression from OP that the disk will be connected most of the time and not a cold storage. For such use case 100% move away to NAS or sync.
Yeah, I also worry that the cells don’t get refreshed often enough and loose the charges. I don’t know how well the controllers will function without their assumed HMB.
I guess I’ll buy a dram SSD then.
Use case: it’s not always plugged in, she only plugs it in when she wants to update some accounting excel stuff.
I’ve tried setting up a nas, she doesn’t like that she’s not plugging in something physical. She kept calling me in work, wanting me to come over to double check that its ok, that the same files are backed up.
Right now, she doesn’t store anything in her SSD on her laptop, but opts to store everything on her external HDD. she’s going to drop that thing one day, so I just want to make it more drop proof by changing it to a SSD
Most all consumer drives don’t bother doing any cell refreshing at all (Crucial MX500 seems to be an exception to this), even when plugged in (with the exception of read disturb refreshes).
The problem isn’t as dire as it might sound for this use case though, cells that have had their charge decay can still be read, just at a slow speed, perhaps 1-2 orders of magnitude slower than usual if they contain data that hasn’t been edited in 1-2 years (really rough ballpark figure).
I’m hoping one of the big youtube channels puts out a video on the phenomenon, but I understand that it is very hard to collect data to quantify the problem due to the time scales involved.
+1 I don’t worry about active working files. Don’t see a problem with backing up to flash either, so long as full backups that write all the data new again happen regularly (every few months, say).
But… everything I have gets on spinning rust too. At a basic level it’s 321 where the different media part’s interpreted as one copy on flash, one on a platter.
For most use probably not much, particularly given an enclosure supporting SMART and UASP that’s not thermally poor. Main difference I’ve noticed is, at least on Windows, HMB drives take more DDR bandwidth for a given transfer rate than DRAMed ones. Anecdotal sample, I’m not sure why it’s the case, but I’d expect it to be worse without HMB. 20 Gb USB’s slow enough it’s unlikely to matter, though. 40 Gb might be enough to start noticing if other things are also keeping cores busy. Doesn’t sound like that’s a use case here, though.
Rather an aside at this point, but I have an SN770 I’ve beat the everloving cr*p out of and it’s held up well. TLC for a little bit under the P41 Plus’s QLC pricing (at least where I am) and a bit faster if ever transferred to a 4.0+ M.2 socket. Not sure if the P1’s any better for thermal contact but I’d guess it’s not much different (the SN770’s not great). The P1’s SM2269XT is 12 nm, versus 16 nm for the MP16+, which might help some with thermals.
Entry level for TLC with DRAM that actually has an endurance spec is, hmm… XS70 followed by NM800 Pro and T500. Dropping to 8 nm with an SN850X is only 5% more than the NM800 or T500, though maybe the T500 inherits the MX500’s refreshing.
I’d be skeptical of this unless there’s strong supporting evidence. A given level of data integrity means all writes need to commit within the same timeframe regardless of what the drive is.
No you do not need a DRAM drive, but they still make a small difference, mostly when downloading (or copying!) file(s) that are 10GB+. For a gamer, this is often the case with game updates, for a grandma, not as much.
That is not really the outcome from the discussion - the problem lies in SSD being powered off long enough to break internal maintenance procedures that rewrites those cells.
For example I would consider a solution with permanent power and SSD.
That said the easiest thing you can do is the following:
Configure the drive to appear as folder or permanently the same letter.
Configure SyncTrayzor with the external drive’s folder.
Decide whether to encrypt or not, if you do then backup the keys from SyncTrayzor (This mostly when you are sending the data to a friend and not your own machines.)
Add a device, this device does not have to be on the same network and the transfer protocols are pretty resilient to weird network paths.
Accept the folder and set so it keeps history (or OS level snapshots)
Now you can log on to the device at any time to see how much of the drive is synchronized. If your BFU plugs in the drive for a short period of time - just ask them to keep it there for a moment.
When BFU is stubborn like this, then the only path forward is to change approach. There is no external drive that will be good enough.
I know it’s an older thread, but I wanted to toss in my 2 cents.
Unless Microsoft changed something in their defaults after Windows 7, all caching is disabled for “removable media” to prevent the kind of errors after “dude you don’t need to safely remove the USB flash drives, just plug them out”.
You can see the tickboxes for each individual disk/device from within Computer Management - device’s Properties. I doubt USB SSDs are treated differently (not many have a UPS either).
I doubt it would work anyhow at all, because HMB probably relies on Host DMA to work, thay’s a property of PCIe. Oh, use that Thunderbolt/USB4 due to PCIe? No, DMA should be disabled for pluggable ports/devices from the host’s point of view due to security implications of allowing unrestricted memory access.
I think your right that it’d require thunderbolt/usb4 to get HMB working due to needing DMA. The chipset in the external enclosure probably matters too.
Whole heartedly agree, but convivence trumped security for tb/usb4. I know kernel level DMA protections have been implemented in most OSes for the bus, but I doubt it is “enough” considering the attacker surface it presents.