On 7/25/2021 12:51 PM, Dimiter_Popoff wrote:> If you have no knowledge of how the flash medium is written - which > would normally be the case with USB sticks or SD cards etc. - the most > efficient way to mitigate data loss probability is to do as much > write cacheing as you can afford at system level.One would assume you'd adopt such a strategy regardless -- as the durability of FLASH is limited. (write a piece of code that just keeps rewriting the contents of FLASH and see how long before you get write/verify errors)> Of course again > you will be prone to data loss on unexpected power loss but updating > the write cache will be done at (much) longer intervals and in > relatively brief bursts, thus the probability to be hit gets lower.The usual trick is to just have a mirror of the FLASH contents and flush that to the media when you're pretty sure the ship is sinking. But, if this is *large*, then you risk only partial writes before power drops to an unusable/unreliable level.> The rest can only be got rid of by having large enough caps on > the power supply and an early warning that power has been lost > (usually at the input of the stepdowns and you are running on fumes.I'm not sure that will work with consumer devices. You have no way of knowing how long it will take to reliably flush ALL of the data out to the physical store. Remember, if you have a USB interface, then the interface limits the write rate as well as the media in the device.> Of course you can employ various strategies to mimick flash drive > behaviour at a higher level, Don suggested one, Kent also did, > but these mean having different drivers for different media and > all the consequences of that.Exactly. I use "bare" devices so I can see how they respond -- because the datasheet gives me hard limits. So, I have to worry about a write *failing* (in which case, it's as if I lost power prematurely) but not *other* "unchanged" data being corrupted in the process (neglecting read/write disturb events).> I prefer to talk to standard SCSI > or ATA behaving things and leave it to them to handle their > unique specifics. [I remember how I *had to* introduce write > cacheing at system level, in the mid 90-s I started to do backups > under DPS to magneto-optical devices; early days DPS would > simply update its CAT (Cluster Allocation Table) every time > it got modifier and these sectors got corrupted before the backup > would finish.... :-) ].I think much of that is inconsistent with Dave's idea of "consumer" (which I read as "inexpensive")
Shutdown behavior and flash storage devices
Started by ●July 24, 2021
Reply by ●July 25, 20212021-07-25
Reply by ●July 25, 20212021-07-25
On 7/25/2021 23:27, Don Y wrote:> On 7/25/2021 12:51 PM, Dimiter_Popoff wrote: > ...... > >> Of course again >> you will be prone to data loss on unexpected power loss but updating >> the write cache will be done at (much) longer intervals and in >> relatively brief bursts, thus the probability to be hit gets lower. > > The usual trick is to just have a mirror of the FLASH contents > and flush that to the media when you're pretty sure the ship > is sinking. > > But, if this is *large*, then you risk only partial writes before > power drops to an unusable/unreliable level.Well I think tens of gigabytes for small drives nowadays, what can you do. Cacheing it all just is not feasible. What DPS does is cache directories and CATs on a 4k piece basis (regardless of the disk block size, 512 2048, 4k) and maintains a bitmap for its dirty regions - so when it updates to the medium it writes at least 4k and no more than twice 4095 excessive bytes or something like that.> >> The rest can only be got rid of by having large enough caps on >> the power supply and an early warning that power has been lost >> (usually at the input of the stepdowns and you are running on fumes. > > I'm not sure that will work with consumer devices. You have no way of > knowing how long it will take to reliably flush ALL of the data > out to the physical store.Oh with consumer devices you have not built yourself it will probably never work, of course. They are unlikely to give you an early warning in the first place. If you want to be safer you just use good rotating disks.... I think I read somewhere they do their soft shutdown using the energy in the rotor (and do that since times immemorial), but I have never verified this. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●July 25, 20212021-07-25
On 7/25/2021 2:00 PM, Dimiter_Popoff wrote:> On 7/25/2021 23:27, Don Y wrote: >> On 7/25/2021 12:51 PM, Dimiter_Popoff wrote: >> ...... >> >>> Of course again >>> you will be prone to data loss on unexpected power loss but updating >>> the write cache will be done at (much) longer intervals and in >>> relatively brief bursts, thus the probability to be hit gets lower. >> >> The usual trick is to just have a mirror of the FLASH contents >> and flush that to the media when you're pretty sure the ship >> is sinking. >> >> But, if this is *large*, then you risk only partial writes before >> power drops to an unusable/unreliable level. > > Well I think tens of gigabytes for small drives nowadays, what can you > do. Cacheing it all just is not feasible.Right. OTOH, if your software is pushing large objects to long term storage, it likely WANTS them to be written, there. Caching is a more prudent strategy for small things that may change often (e.g., configuration parameters, "state", etc.) Pushing them to the physical store is LOGICALLY correct (from the application's standpoint) but usually a performance hit and a durability hit (for media that wear).> What DPS does is cache directories and CATs on a 4k piece basis > (regardless of the disk block size, 512 2048, 4k) and maintains a > bitmap for its dirty regions - so when it updates to the medium > it writes at least 4k and no more than twice 4095 excessive bytes > or something like that.I only have persistent memory in my RDBMS -- everything else is just RAM (save for small bootloaders). But, the RDBMS node can afford to have gobs of disk cache to avoid physical writes. And, I can use different "tablespaces" (the "disk" on which particular "tables" reside) to deliberately avoid backing certain tables (like temporary ones) to durable memory.>>> The rest can only be got rid of by having large enough caps on >>> the power supply and an early warning that power has been lost >>> (usually at the input of the stepdowns and you are running on fumes. >> >> I'm not sure that will work with consumer devices. You have no way of >> knowing how long it will take to reliably flush ALL of the data >> out to the physical store. > > Oh with consumer devices you have not built yourself it will probably > never work, of course. They are unlikely to give you an early warning > in the first place. If you want to be safer you just use good rotating > disks.... I think I read somewhere they do their soft shutdown using the > energy in the rotor (and do that since times immemorial), but I have > never verified this.I think the first step is questioning what you *need* to store. E.g., I trade memory for time with a lot of my algorithms -- pulling data from disk and using that to build large structures in RAM that I can use to expedite the algorithms. It would be *nice* to be able to save those structures in their "large" state -- to save the time/effort of having to rebuild them when I restart those applications. But, this gets to be costly if you try to adopt that practice universally (with all applications). And, of course, making sure you can "recognize" data that is corrupt...
Reply by ●July 27, 20212021-07-27
On 24-07-2021 17:19, Dave Nadler wrote:> Hi All - I'm wondering what other folks do about this issue... > > Consumer flash storage devices (USB memory stick, SD card, etc) > have a nice internal wear-leveling controller. When one does a write > operation, lots of sectors may be internally rejiggered to provide > uniform wear (so things that are never rewritten from the application > point of view are actually moved around and rewritten). This activity is > invisible from normal application's point of view, but takes some time. > If the device is powered off during such activity, data corruption... > So, its necessary to provide the device some time after the last write > before it is powered off. Plenty of embedded stuff I've seen too often > corrupts memory at power off, and of course the device manufacturers > blame the memory manufacturers... > > So, how do you avoid this kind of corruption in your designs? > > Thanks, > Best Regards, DaveA number of upper tier memory device manufacturers sell flash drives, USB sticks, SS Sata drives and M2 drives with "UPS" capabilities. When they sense a loss of power they will have just enough onboard juice to power down in a controller manner. I have used drives from InnoDisk ( https://www.innodisk.com/en/products/flash-storage/ssd ) on Linux boxes inside machines with hard on/off switches. With regular drives we'd see boot problems after 20 to 30 power cycles, with the "UPS" protected ones we could do hundreds of hard cycles without ill effect. Antoon
Reply by ●July 27, 20212021-07-27
On 7/27/2021 10:44 AM, Jaded Hobo wrote:> On 24-07-2021 17:19, Dave Nadler wrote: >> Hi All - I'm wondering what other folks do about this issue... >> >> Consumer flash storage devices (USB memory stick, SD card, etc) >> have a nice internal wear-leveling controller. When one does a write >> operation, lots of sectors may be internally rejiggered to provide uniform >> wear (so things that are never rewritten from the application point of view >> are actually moved around and rewritten). This activity is invisible from >> normal application's point of view, but takes some time. If the device is >> powered off during such activity, data corruption... So, its necessary to >> provide the device some time after the last write before it is powered off. >> Plenty of embedded stuff I've seen too often corrupts memory at power off, >> and of course the device manufacturers blame the memory manufacturers... >> >> So, how do you avoid this kind of corruption in your designs? >> >> Thanks, >> Best Regards, Dave > > A number of upper tier memory device manufacturers sell flash drives, USB > sticks, SS Sata drives and M2 drives with "UPS" capabilities. When they sense a > loss of power they will have just enough onboard juice to power down in a > controller manner. > > I have used drives from InnoDisk ( > https://www.innodisk.com/en/products/flash-storage/ssd ) on Linux boxes inside > machines with hard on/off switches. With regular drives we'd see boot problems > after 20 to 30 power cycles, with the "UPS" protected ones we could do hundreds > of hard cycles without ill effect.What's the (typical) price premium for that "feature"?
