Re: SSD's and many edits of a single file
On Tuesday 10 April 2018 22:24:39 David Christensen wrote:
> On 04/09/18 20:58, Gene Heskett wrote:
> > 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.
>
> They both seem to involve getting blocks from an app to memory and
> blocks from memory to disk (and/or disk to memory). They could be
> variations on a theme.
>
>
> Can you reproduce the bugs on a machine with straight-up Debian (e.g.
> no linuxcnc)?
>
That to me would be rather pointless. The only places where I be doing
wholesale edits would be for linuxcnc use.
>
> As a safety net, I would suggest a versioning file system (e.g.
> similar to the versioning feature of VMS). STFW is pretty thin, but
> copyfs might be worth a try:
This "fuse" would be on top of ext4? Or on an SSD that was a copy of this
one but using fuse as opposed to ext4?
What seems to be lost on you folks not running realtime patched kernels,
is that when linuxcnc is running, it has total control over the
hardware, and that linux becomes a client of the realtime system,
getting what cpu time is left after linuxcnc has finished what it has to
do to meet the timing constraints needed to run the machine and meet the
sub-micron positioning accuracy required.
Not your fault of course because to you its effectively real time if you
do not see a lag between touching a key and the response on screen. But
a 20ns response time is about 3 orders of magnitude faster than that
which is realtime to you.
> https://packages.debian.org/search?keywords=copyfs&searchon=names&suit
>e=all§ion=all
This link shows 2 versions, but only the older, 1.4 might be usable since
the newest system I'm running is jessie on an r-pi-3b. Stretch so far is
not stable on arm64, aka a rock64 yet. Even running an amanda client on
the arm64 can take it down. Downgrade its install to a jessie derived
version and its dead stable. And amanda is dead stable on 6 of the 7
systems with a net cable plugged into it here.
But this link does not contain a sales pitch describing what it can do
and why it should be used, a common fault, I think because git doesn't
seem to have a "box" category to put this stuff into for ready
presentation when browsing around looking for a solution to a problem.
This lack of a descriptive sales pitch "box" for this info is, IMNSHO, a
major failing of the linux genre. There may well be a magic twanger or 8
out there, but searching the repo's is less than useful in many cases.
All this of course has drifted off-topic, debian moves a bit slow and
does not actually support the arm64 yet. That I understand is a lack of
manpower problem. Were I 40 years younger, I might be able to help a wee
bit. But I'm not, and having had a pulmonary embolism that damned near
put a ~30~ on my story 3 years back, I can feel the wet ram damage that
caused.
I think that by changing how I work, so that an edit is done with a fresh
invocation of the editor each time, that I will not see this problem
again, so we should really put this thread to bed.
"Magic Twanger" and Froggie indeed, that kiddie tv show is now 68 years
old. I guess that does date me. 99% of the readers of this message have
no clue where that phrase came from.
> 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: