Web lists-archives.com

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




On 04/11/18 00:27, Gene Heskett wrote:
On Tuesday 10 April 2018 22:24:39 David Christensen wrote:
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.

If geany and gedit fail on a machine with Debian plus LinuxCNC, but work correctly on a machine with Debian alone, that would indicate the bug is related to LinuxCNC.


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?

Here is information about FUSE:

https://en.wikipedia.org/wiki/Filesystem_in_Userspace


See link below for information about copyfs.


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.

I used to work as a embedded systems software engineer back in the dot-com days. My niche was controlling electro-mechanical systems using 8051, 68xx, and 68xxx micro-controllers. I have written C and assembly language drivers and programs to meet soft and hard real-time requirements, including stepper motor sequencing. I had heard of hard real-time kernels that used Linux as their idle loop. I have since used Linux real-time patches for my audio and music hobbies.


https://packages.debian.org/search?keywords=copyfs&searchon=names&suit
e=all&section=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,

Here is information about copyfs:

https://boklm.eu/copyfs/


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.

I used VMS systems back in the 1980's, and VMS's versioning file system was a killer feature that I would love to have on my Linux machines today:

https://mike632t.wordpress.com/2016/03/15/vms-file-operations-for-beginners/


Unfortunately, the semantics of copyfs appear to differ.


"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.

STFW I see Andy's Gang (but it's before my time):

https://www.youtube.com/watch?v=G6a3fck0NBI


Thanks David.

Thanks for the interesting problem to think about.  :-)


David