[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SSD's and many edits of a single file

On 04/09/18 07:30, Gene Heskett wrote:

On Monday 09 April 2018 09:51:37 Greg Wooledge wrote:


On Mon, Apr 09, 2018 at 09:46:07AM -0400, rhkramer@gmail.com
wrote:

To your original problem, have you tried going to a command line
and throwing in a couple =sync=s?  I would try that, maybe after
saving in your editor, and again maybe after open and / or saving
in the cnc program.
As others have explained, the OS (Linux) keeps a cache of file contents that have been written by applications, but not yet 
committed to permanent storage.  If you "save" from within the text
editor, then the saved contents should be immediately visible to
other processes reading the file, regardless of whether it has been
synced to disk. They'll simply get the cached version.


Which is not happening after several hours and a hundred or more
edits. Which is why its so intermittent.


On 04/09/18 02:53, Gene Heskett wrote:

Lots of people seem to like gedit, but its saves are the cause of
important configuration files being written back to disk with the
line order totally trashed, as if you had thrown it on the floor in
512 byte pieces, then picked it back up and reassembled it in random
order. Then try to recover a 1400 LOC configuration file...

Thats happened using gedit enough, on several different machines ...


One editor failing would also make me suspect the editor.
But two failing editors would make me suspect some common factor, such as a shared library and/or the kernel.
Have you tested your hardware -- power supply, memory, and SSD? Be sure to test the SSD before you touch any cables. If it fails, re-seat and/or replace cables and test again.
Have you tested your SSD hypothesis? Say, by removing the SSD, cloning the SSD to another device, installing the other device, and then testing for the bug while running the other device?
Can you reproduce the bug on hardware with ECC memory with no memory errors reported? 


Can you reproduce the bug on RAID1 with no RAID errors reported?


If you want to make it possible for others to find the bug, I would suggest:
1. Build a machine with the minimum hardware, software, and configuration required to demonstrate the bug. Document everything.
2. Write a program or script that invokes the bug every time it runs on the demonstration machine. If a program, include a Makefile.
3. Post the demonstrator document, program, script, Makefile, etc., to the relevant support communities. 


David
Reply to: