I'm facing a recurring problem of frequent flash drive failure on dedicated systems running Windows XP. Whether the drive in question is CF (compact flash) or a flash module, the drive typically dies in a couple of years. I'm suspecting that the NTFS journaling file system wears out certain locations by writing to them too often. Can someone please suggest a way of mitigating this issue? The computers in which this problem is occurring are small, single board computers. There is no space (physically) to install a conventional 2.5" HDD. The application software won't run on a newer OS. EDITED to remove use of the term 'solid state drive' as it was causing confusion. Although Flash drives are technically solid state, they do differ from what we now consider to be SSDs, as John Sutherland rightly pointed out.
for all os < win7 you need a ssd wich has a software tool from the manufactory of the SSD this tool must 1. optimize the partition(s) of the SSD - os like win xp set the partitions boundery wrong for SSD) 2. set enough free (non-partitioned area) space for replace damaged memory zells (S.M.A.R.T Check technology) 3. have a trimm tool (better a trimm service wich automatic do a Performance Optimization of the SSD) on eg win xp you have also disable many features like system optimize (wich is for hd's) and defragment for >= win7 to < win 10 you need this tool also for point 1 and 2 point 1 and 2 must well done bevore you install windows afaik only win 10 do this automatic during the installation without this you only damage the SSD itself and never get a running system
Just so you're aware, the O.P. isn't asking about SSD's. His problem is with using CF cards to run Windows XP on a computer that lacks a conventional HDD drive bay. HDD or SSD is not an option.
sorry have never seen a computer without 2.5' bay and no M2 bay have also never seen a computer wich only have CF card bay for a OS running a win xp from a CF card is realy nonsense
you are way off topic, vanelle. if you cannot read and cannot contribute, please stay out of this thread, and please don`t start screaming about nonsense, before you even realize what is needed here. you really never saw a single board computer, like op has just told you?really??? and you want to contribute to this thread?? really?? then you are a mere troll,, in my book, posting utter nonsense.....
thanks a lot for clarification and change of the topick why you exploring options to squeeze in 1.8" HDDs ? from the bort design i see that it has a Mini PCIe slot - 1 x Full-size (default supports SATA and USB, PCIe is supported by request) i suggest you exploring to conect the 1.8" HDDs to this slot why not locking for a adapter / cable from Mini PCIe slot (pins) to a M.2 adapter for a SSD ? a M.2 adapter with a SSD is much smaller then a 1.8" HDD and 120GB SSD is more cheeper or is this not a option ?
Putting in an SSD will not fix the problem unless the SSD controller inside/onboard the SSD does the wear leveling automatically. Otherwise XP will write tiny amounts of data repeatedly to the same locations and wear those out as well. Might take longer than FLASH, but it will still fail. The data logging by the application software, as well as the data written by the LabView drivers themselves is likely what is causing the relatively frequent failures. I will see if disabling the timestamps as suggested by John Sutherland is compatible with the application software. For all I know LabView might be using those timestamps.
yes i understand, but a big problem is the disproportion between the free space and the files from the os and the App's (in my eyes big design mistake of the SBC) max 60GB on bort SATA FLASH is ok for XP Embedded system, but not for full Windows XP in case of the 'on bord SATA 60GB' (ths is the minimun for XP) i guess lats say 85% from the 60GB are fixed and only read the 15 % free space are always rewriten (the same nands or whatever) - this burns holes in the memory if the free space is much bigger (eg 120 or 250GB ssd) there is much more free space wich can be used - this incrase the livetime exponential not linear ! and a trim service can implement by a task) an a bigger SSD has also more free partitions-space for the smartleveling (10-20%) as you say 1.8" HDDs (which cost more than the SBC).