Re: SSD's and many edits of a single file
On Monday 09 April 2018 21:25:34 David Christensen wrote:
> 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.
>
I'd buy that if the failures were similar. They are not.
>
> 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.
I saw this once when the drive was a 2T piece of spinning rust. Way
overkill for that machine, but a 1T is being used for amanda, here on
this machine and its around 90% right now. So at some
point "/amandatapes" is going to find another terabyte.
>
> 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?
I have a twin to that one, but only one handy sata port. So it would be
an extended project to clone it to the other drive. And since I saw it
on spinning rust too, I'm not inclined to sharpen that finger just yet.
That machine has also ran about 7 cycles of memtest86 with no errors
since I noticed it the first time.
> Can you reproduce the bug on hardware with ECC memory with no memory
> errors reported?
I don't have anything with ECC memory in it. That usually runs the mobo
cost up quite a ways.
> Can you reproduce the bug on RAID1 with no RAID errors reported?
That would also demand another handy sata port. I'll see if I can cobble
something up if and when it does it again. Possible if it has a back
panel sata connector I think.
>
> 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
Thanks David.
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: