Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264685 > unrolled thread

raid10 is killing me, and applications that aren't willing to wait for it to respond

Back to article view | Back to linux.debian.user

Contents

  raid10 is killing me, and applications that aren't willing to wait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-13 16:30 +0100
    Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond Tom Furie <tom@furie.org.uk> - 2023-12-13 16:50 +0100
      Re: raid10 is killing me, and applications that aren't willing towait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-13 19:20 +0100
        Re: raid10 is killing me, and applications that aren't willing  towait for it to respond Tom Furie <tom@furie.org.uk> - 2023-12-13 20:00 +0100
          Re: raid10 is killing me, and applications that aren't willingtowait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-13 20:30 +0100
    Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond Pocket <pocket@columbus.rr.com> - 2023-12-13 18:00 +0100
      Re: raid10 is killing me, and applications that aren't willing towait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-13 19:30 +0100
        Re: raid10 is killing me, and applications that aren't willing  towait for it to respond Nicolas George <george@nsup.org> - 2023-12-13 19:50 +0100
          Re: raid10 is killing me, and applications that aren't willing towait  for it to respond Pocket <pocket@columbus.rr.com> - 2023-12-13 20:10 +0100
        Re: raid10 is killing me, and applications that aren't willing towait  for it to respond Pocket <pocket@columbus.rr.com> - 2023-12-13 19:50 +0100
          Re: raid10 is killing me, and applications that aren't willing  towait for it to respond Dan Ritter <dsr@randomstring.org> - 2023-12-13 20:10 +0100
            Re: raid10 is killing me, and applications that aren't willing towait  for it to respond Pocket <pocket@columbus.rr.com> - 2023-12-13 20:20 +0100
            Re: raid10 is killing me, and applications that aren't willingtowait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-13 20:30 +0100
    Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-13 19:30 +0100
      Re: raid10 is killing me, and applications that aren't willing  towait for it to respond "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-13 23:00 +0100
        Re: raid10 is killing me, and applications that aren't willingtowait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-14 01:10 +0100
    Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond Andy Smith <andy@strugglers.net> - 2023-12-13 22:40 +0100
      Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond Andy Smith <andy@strugglers.net> - 2023-12-14 00:10 +0100
      Re: raid10 is killing me, and applications that aren't willing towait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-14 00:40 +0100
        Re: raid10 is killing me, and applications that aren't willing towait  for it to respond David Christensen <dpchrist@holgerdanske.com> - 2023-12-14 04:20 +0100
    Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond <tomas@tuxteam.de> - 2023-12-14 06:50 +0100
      Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond Nicolas George <george@nsup.org> - 2023-12-14 10:20 +0100
        Re: raid10 is killing me, and applications that aren't willing to  wait for it to respond <tomas@tuxteam.de> - 2023-12-14 10:40 +0100
        Re: raid10 is killing me, and applications that aren't willing towait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-14 13:10 +0100
      Re: raid10 is killing me, and applications that aren't willing towait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-14 12:00 +0100
        Re: raid10 is killing me, and applications that aren't willing towait for it to respond Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-14 22:40 +0100
          Re: raid10 is killing me, and applications that aren't willing towait  for it to respond gene heskett <gheskett@shentel.net> - 2023-12-15 03:40 +0100
            Re: raid10 is killing me, and applications that aren't willing towait  for it to respond David Christensen <dpchrist@holgerdanske.com> - 2023-12-15 09:10 +0100
              Re: raid10 is killing me, and applications that aren't willing  towait for it to respond Andy Smith <andy@strugglers.net> - 2023-12-15 13:30 +0100
                Re: raid10 is killing me, and applications that aren't willing towait for it to respond Stefan Monnier <monnier@iro.umontreal.ca> - 2023-12-15 16:00 +0100
              Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond gene heskett <gheskett@shentel.net> - 2023-12-16 03:30 +0100
                Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond David Christensen <dpchrist@holgerdanske.com> - 2023-12-16 05:00 +0100
                  Re: raid10 is killing me, and applications that aren't  willingtowaitfor it to respond gene heskett <gheskett@shentel.net> - 2023-12-16 16:10 +0100
                    Re: raid10 is killing me, and applications that aren't  willingtowaitfor it to respond David Christensen <dpchrist@holgerdanske.com> - 2023-12-16 21:30 +0100
                Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond David Christensen <dpchrist@holgerdanske.com> - 2023-12-16 05:10 +0100
                  Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond Matt <matt@jmgresham.xyz> - 2023-12-16 05:20 +0100
                    Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond Greg Wooledge <greg@wooledge.org> - 2023-12-16 05:30 +0100
                      Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond Matt <matt@jmgresham.xyz> - 2023-12-16 05:30 +0100
                      Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-16 09:30 +0100
                        Re: raid10 is killing me, and applications that aren't willing  towaitfor it to respond David Christensen <dpchrist@holgerdanske.com> - 2023-12-16 20:20 +0100
            Re: raid10 is killing me, and applications that aren't willing towait for it to respond Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2023-12-16 09:50 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#264719 — Re: raid10 is killing me, and applications that aren't willing to wait for it to respond

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 13, 2023 at 10:26:19AM -0500, gene heskett wrote:
> Greetings all;
> 
> I thought I was doing things right a year back when I built a raid10 for my
> /home partition. but I'm tired of fighting with it for access. Anything that
> wants to open a file on it, is subjected to a freeze of at least 30 seconds
> BEFORE the file requester is drawn on screen.  Once it has done the screen
> draw and the path is established, read/writes then proceed at multi-gigabyte
> speeds just like it should [...]

 - disk access latency
 - digikam
 - photo volume monitor
 - cache buffers (which?)
 - klipper

> I've been here several times with this problem without any constructive
> responses [...]

> So one more time: Why can't I use my software raid10 on 4 1T SSD's ?????

Gene, just a humble suggestion. I'm too short in time to wade through all
this deep software cake, of which I know but a fraction.

Perhaps if you structured your requests a bit better, the quality of the
answers would improve?

I've skimmed some of the answers, and they correspond to your confusing
request. Someone mentions DNS timeouts to rule them out right away (do
you access your RAID over the net? Is DNS resolution involved at all?)

Other answers veer of in similar disparate directions, but that corresponds
to your request's deeply confusing nature.

Let me humbly suggest to structure your search a bit (you do have deep
experience in fault searching, we all know).

What I get from your post is that you seem to see the root of your problems
in a long latency on (first?) storage access to your block device (whether
it matters that it be a RAID10 or a RAID42 we just don't know!).

This looks like a promising avenue, so let's pretend we start with this
one.

Do you experience this latency also with simpler tools (something which
doesn't "draw a requester on screen", like, say, ls or find)?

Let's thus try to rule out the deep pie of sh*** (uh, software stack)
you are using to access the disk. Do you still observe this latency?
Is there a pattern (like, when accessing something for the first time,
and/or accessing things after a longer inactivity period, yadda, yadda).

If yes, you can follow the path "disk access latency". If no, the problem
might lie further up the stack (and then, things like DNS latencies might
play a role again!).

With your posts, my head spins and my time slot in the mornings, before
I go to $DAYJOB is used up before I can start even to think about how
debug things.

In one short word: please focus. Debugging complex stuff becomes impossible
otherwise.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#264725 — Re: raid10 is killing me, and applications that aren't willing to wait for it to respond

tomas@tuxteam.de (12023-12-14):
> I've skimmed some of the answers, and they correspond to your confusing
> request. Someone mentions DNS timeouts to rule them out right away (do
> you access your RAID over the net? Is DNS resolution involved at all?)

He quoted:

>> Error creating proxy: Error calling StartServiceByName for
>> org.gtk.vfs.GPhoto2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)

That means the issue is in the DBus monster moussaka¹. The odds of
finding a solution in the current circumstances are vanishingly thin.

Regards,

-- 
  Nicolas George


1: Some software are a mess of dependencies and calls, like the pipes in
a gasworks factory; some software are worse.

[toc] | [prev] | [next] | [standalone]

#264726 — Re: raid10 is killing me, and applications that aren't willing to wait for it to respond

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 14, 2023 at 10:17:23AM +0100, Nicolas George wrote:
> tomas@tuxteam.de (12023-12-14):
> > I've skimmed some of the answers, and they correspond to your confusing
> > request. Someone mentions DNS timeouts to rule them out right away (do
> > you access your RAID over the net? Is DNS resolution involved at all?)
> 
> He quoted:
> 
> >> Error creating proxy: Error calling StartServiceByName for
> >> org.gtk.vfs.GPhoto2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)
> 
> That means the issue is in the DBus monster moussaka¹.

At least this is a more polite metaphor than the one I used, thanks.

>                                                       The odds of
> finding a solution in the current circumstances are vanishingly thin.

Perhaps, perhaps not. May be the root cause is just, as Gene's hunch
seems to be, the disk latency [1] and you are killing the messenger
(which, of course, has disgustingly many tentacles).

That's why I implored Gene to muster up his analytical fu and to cut
with a sharp razor.

Cheers

[1] whoknows. Perhaps some energy saving parameter is set up in an
   insanely aggresive mode, perhaps this interacts in strange ways
   with the RAID controller...

   Then, perhaps it's just the moussaka. Then, DNS timeouts are
   plausible. As, perhaps, ChatGPT latencies are.
-- 
t

[toc] | [prev] | [next] | [standalone]

#264730 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

On 12/14/23 04:17, Nicolas George wrote:
> tomas@tuxteam.de (12023-12-14):
>> I've skimmed some of the answers, and they correspond to your confusing
>> request. Someone mentions DNS timeouts to rule them out right away (do
>> you access your RAID over the net? Is DNS resolution involved at all?)

no, and no.

> He quoted:
> 
>>> Error creating proxy: Error calling StartServiceByName for
>>> org.gtk.vfs.GPhoto2VolumeMonitor: Timeout was reached (g-io-error-quark, 24)
> 
The odd part of that is that there is, stuck on screen on every 
workspace, a volume control gui of some kind that has no exit icon. I 
cannot get rid of it. It has a wrench icon where most gui's have an exit 
button. And that lead to a red trash can icon labeled remove widget, and 
it did, whatever the heck a widget is.

> That means the issue is in the DBus monster moussaka¹. The odds of
> finding a solution in the current circumstances are vanishingly thin.
> 
> Regards,
> 

Cheers, Nik, 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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264727 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

On 12/14/23 00:39, tomas@tuxteam.de wrote:
> On Wed, Dec 13, 2023 at 10:26:19AM -0500, gene heskett wrote:
>> Greetings all;
>>
>> I thought I was doing things right a year back when I built a raid10 for my
>> /home partition. but I'm tired of fighting with it for access. Anything that
>> wants to open a file on it, is subjected to a freeze of at least 30 seconds
>> BEFORE the file requester is drawn on screen.  Once it has done the screen
>> draw and the path is established, read/writes then proceed at multi-gigabyte
>> speeds just like it should [...]
> 
>   - disk access latency
>   - digikam
>   - photo volume monitor
>   - cache buffers (which?)
>   - klipper
> 
>> I've been here several times with this problem without any constructive
>> responses [...]
> 
>> So one more time: Why can't I use my software raid10 on 4 1T SSD's ?????
> 
> Gene, just a humble suggestion. I'm too short in time to wade through all
> this deep software cake, of which I know but a fraction.
> 
> Perhaps if you structured your requests a bit better, the quality of the
> answers would improve?

The latest info is that non-gui stuff works instantly. gui stuff lags at 
least 30 seconds, mouse still moves but the rest of the same screen is 
non-responsive until this tomeout has taken place, then everything 
returns to normal.

> I've skimmed some of the answers, and they correspond to your confusing
> request. Someone mentions DNS timeouts to rule them out right away (do
> you access your RAID over the net? Is DNS resolution involved at all?)

no
> Other answers veer of in similar disparate directions, but that corresponds
> to your request's deeply confusing nature.

Because I was not able to define it any better.

> 
> Let me humbly suggest to structure your search a bit (you do have deep
> experience in fault searching, we all know).
> 
> What I get from your post is that you seem to see the root of your problems
> in a long latency on (first?) storage access to your block device (whether
> it matters that it be a RAID10 or a RAID42 we just don't know!).

As I also don't know, this raid10 is my only experience with a raid of 
any kind.

> 
> This looks like a promising avenue, so let's pretend we start with this
> one.
> 
> Do you experience this latency also with simpler tools (something which
> doesn't "draw a requester on screen", like, say, ls or find)?

no, even a dd write is essentially instant.

> Let's thus try to rule out the deep pie of sh*** (uh, software stack)
> you are using to access the disk. Do you still observe this latency?
> Is there a pattern (like, when accessing something for the first time,
> and/or accessing things after a longer inactivity period, yadda, yadda).

It repeats per gui access. Starting a gfx program such as OpenSCAD, or 
qidislicer from an xfce4 terminal cli, is delayed for this similar but 
not always identical lag. And reports odd warnings etc while its getting 
ready to open its gui.

Might there be a clue there?  IDK  I could copy/paste some of it if you 
like to see it, but to me it doesn't look related or I would have already.
> 
> If yes, you can follow the path "disk access latency". If no, the problem
> might lie further up the stack (and then, things like DNS latencies might
> play a role again!).
> 
> With your posts, my head spins and my time slot in the mornings, before
> I go to $DAYJOB is used up before I can start even to think about how
> debug things.

And I appreciate that Tomas, $DAYJOBS take precedence, always. Triply 
appreciated when you are the only tech person responsible for keeping a 
tv station on the air and working smoothly like I was for nearly 50 
years before I retired, its not a $DAYJOB, its a $24/7/365.25JOB.

> In one short word: please focus. Debugging complex stuff becomes impossible
> otherwise.

I now think I have a gui problem and can imagine something in the 
original debian gnome install getting the request to open the gui and 
has to fail before xfce4 even gets the request. Whether that is true or 
not, is up to ways to test the theory. That I'm clueless about.  There 
is enough kde/plasma installed that it thinks it has to start kmail at 
boot time, lots of kde and gnome leftovers, but the popups asking for a 
pw, are also subjected to this delay after the bootup is completed. Is 
this all connected? At this time IDK.

> Cheers

Thank you Tomas.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264755 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

gene heskett <gheskett@shentel.net> writes:

> It repeats per gui access. Starting a gfx program such as OpenSCAD, or
> qidislicer from an xfce4 terminal cli, is delayed for this similar but 
> not always identical lag. And reports odd warnings etc while its
> getting ready to open its gui.

Does this happen with common GUI tools too like, say, Firefox? Or XFCE's
file manager, Thunar I believe? Or a text editor like Gedit? Or even the
XFCE terminal?

[toc] | [prev] | [next] | [standalone]

#264767 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

On 12/14/23 16:36, Anssi Saari wrote:
> gene heskett <gheskett@shentel.net> writes:
> 
>> It repeats per gui access. Starting a gfx program such as OpenSCAD, or
>> qidislicer from an xfce4 terminal cli, is delayed for this similar but
>> not always identical lag. And reports odd warnings etc while its
>> getting ready to open its gui.
> 
> Does this happen with common GUI tools too like, say, Firefox? 
firefox, no.
Or XFCE's
> file manager, Thunar I believe?
Thunar, yes, but I don't use it, not my cup of tea.  It wants to be a 
replacement for mc, but fails at 90% of what mc can do.


  Or a text editor like Gedit?

Gedit has ben banned from any of my machines for at least 15 years, it 
made scrambled eggs out of of several linuxcnc configuration files I had 
to re-write from scratch, but geany has never done that.  And geany is 
as instant as nano.

  Or even the
> XFCE terminal?
Comes up instantly from the menu, I use it heavily because it has tabs. 
I use them much like workspaces.

Is this info helpful?

Thank you Anssi Saari

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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264772 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

On 12/14/23 18:36, gene heskett wrote:
> On 12/14/23 16:36, Anssi Saari wrote:
>> gene heskett <gheskett@shentel.net> writes:
>>
>>> It repeats per gui access. Starting a gfx program such as OpenSCAD, or
>>> qidislicer from an xfce4 terminal cli, is delayed for this similar but
>>> not always identical lag. And reports odd warnings etc while its
>>> getting ready to open its gui.
>>
>> Does this happen with common GUI tools too like, say, Firefox? 
> firefox, no.
> Or XFCE's
>> file manager, Thunar I believe?
> Thunar, yes, but I don't use it, not my cup of tea.  It wants to be a 
> replacement for mc, but fails at 90% of what mc can do.
> 
> 
>   Or a text editor like Gedit?
> 
> Gedit has ben banned from any of my machines for at least 15 years, it 
> made scrambled eggs out of of several linuxcnc configuration files I had 
> to re-write from scratch, but geany has never done that.  And geany is 
> as instant as nano.
> 
>   Or even the
>> XFCE terminal?
> Comes up instantly from the menu, I use it heavily because it has tabs. 
> I use them much like workspaces.
> 
> Is this info helpful?
> 
> Thank you Anssi Saari
> 
> Cheers, Gene Heskett.


It sounds like OpenSCAD and gidislicer have something in common that is 
causing the issue, while the other apps do not have that something.  So, 
the challenge is finding the shared object files (dynamic linking) 
and/or the source files (static linking) that are present in the 
affected programs and not present in the unaffected programs.


It would be helpful if you posted a list of affected programs and a list 
of unaffected programs to provide alternatives for a search.  Please 
note any programs that you did not install using conventional Debian 
packages (and that may be the root cause of the issue).


David

[toc] | [prev] | [next] | [standalone]

#264774 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

Hello,

On Fri, Dec 15, 2023 at 12:00:00AM -0800, David Christensen wrote:
> On 12/14/23 18:36, gene heskett wrote:
> > Thunar, yes, but I don't use it, not my cup of tea.

[…]

> It sounds like OpenSCAD and gidislicer have something in common that is
> causing the issue, while the other apps do not have that something.  So, the
> challenge is finding the shared object files (dynamic linking) and/or the
> source files (static linking) that are present in the affected programs and
> not present in the unaffected programs.

I will add that the Thunar file manager was included in Gene's
"affected" list and I think Gene posted some logs before that showed
some dbus timeout.

I've no idea how to start debugging this but I feel like the problem
may exist somewhere in Gene's desktop environment and affect
things that call its file dialog.

Anyway, I think we can all agree at this point that this has got
nothing to do with RAID and mdadm. Though Gene said he has tried to
reinstall several times I think, with the same outcome, so it's not
something that's going to be avoided by another install otherwise I
might suggest that.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#264786 — Re: raid10 is killing me, and applications that aren't willing towait for it to respond

> I've no idea how to start debugging this but I feel like the problem

`strace` maybe?


        Stefan

[toc] | [prev] | [next] | [standalone]

#264791 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

On 12/15/23 06:17, David Christensen wrote:
> On 12/14/23 18:36, gene heskett wrote:
>> On 12/14/23 16:36, Anssi Saari wrote:
>>> gene heskett <gheskett@shentel.net> writes:
>>>
>>>> It repeats per gui access. Starting a gfx program such as OpenSCAD, or
>>>> qidislicer from an xfce4 terminal cli, is delayed for this similar but
>>>> not always identical lag. And reports odd warnings etc while its
>>>> getting ready to open its gui.
>>>
>>> Does this happen with common GUI tools too like, say, Firefox? 
>> firefox, no.
>> Or XFCE's
>>> file manager, Thunar I believe?
>> Thunar, yes, but I don't use it, not my cup of tea.  It wants to be a 
>> replacement for mc, but fails at 90% of what mc can do.
>>
>>
>>   Or a text editor like Gedit?
>>
>> Gedit has ben banned from any of my machines for at least 15 years, it 
>> made scrambled eggs out of of several linuxcnc configuration files I 
>> had to re-write from scratch, but geany has never done that.  And 
>> geany is as instant as nano.
>>
>>   Or even the
>>> XFCE terminal?
>> Comes up instantly from the menu, I use it heavily because it has 
>> tabs. I use them much like workspaces.
>>
>> Is this info helpful?
>>
>> Thank you Anssi Saari
>>
>> Cheers, Gene Heskett.
> 
> 
> It sounds like OpenSCAD and gidislicer have something in common that is 
> causing the issue, while the other apps do not have that something.  So, 
> the challenge is finding the shared object files (dynamic linking) 
> and/or the source files (static linking) that are present in the 
> affected programs and not present in the unaffected programs.
> 
> 
> It would be helpful if you posted a list of affected programs and a list 
> of unaffected programs to provide alternatives for a search.  Please 
> note any programs that you did not install using conventional Debian 
> packages (and that may be the root cause of the issue).
> 
I use the bleeding edge AppImage version of OpenSCAD, heavily, it has no 
such problems.  And no error outputs on the cli, it Just Works.

QIDISlicer gives these two errors instantly on launch from cli
Cannot register URI scheme wxfs more than once

** (qidi-slicer:24330): CRITICAL **: 12:29:20.900: Cannot register URI 
scheme memory more than once

QIDISlicer has jillions of gtk2 things:
(qidi-slicer:24330): Gtk-CRITICAL **: 12:29:21.017: 
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar

(qidi-slicer:24330): Gtk-CRITICAL **: 04:04:12.705: 
gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
including 50+ of the second, and many more gtk_gedget as it opens and 
works.  And I blame the packager since there is no more gtk2 in the 
debian repo's.

Cura, latest 5.5.0 AppImage has a few warnings but opens in about 10 
seconds and works fine from there.

There are other AppImages but most either won't run or fail if writing.

digiKam v8.2.0 cannot import from my camera because (and this is a swag) 
it cannot get instant write perms. It can see everything in the camera, 
but cannot download anything. And does not report any errors on the cli 
when it fails.  It goes thru te motions, blinking all the lights, but 
gimp cannot find the images it just went thru the motions of downloading.

Shotwell has the delay, and can import from the camera.

Spectacle works in 5 secs, but kills plasma as it exits.

Thank you 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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264793 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

On 12/15/23 18:23, gene heskett wrote:
> I use the bleeding edge AppImage version of OpenSCAD, heavily, it has no 
> such problems.  And no error outputs on the cli, it Just Works.


Thank you for the reply.  :-)


Do you mean the following?

https://openscad.org/downloads.html

OpenSCAD-2021.01-x86_64.AppImage.asc


> QIDISlicer gives these two errors instantly on launch from cli
> Cannot register URI scheme wxfs more than once
> 
> ** (qidi-slicer:24330): CRITICAL **: 12:29:20.900: Cannot register URI 
> scheme memory more than once
> 
> QIDISlicer has jillions of gtk2 things:
> (qidi-slicer:24330): Gtk-CRITICAL **: 12:29:21.017: 
> gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
> 
> (qidi-slicer:24330): Gtk-CRITICAL **: 04:04:12.705: 
> gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
> including 50+ of the second, and many more gtk_gedget as it opens and 
> works.  And I blame the packager since there is no more gtk2 in the 
> debian repo's.


Which QIDISlicer -- e.g. version?

Where did you get it -- e.g. Debian package, AppImage, source tarball, etc.?


> Cura, latest 5.5.0 AppImage has a few warnings but opens in about 10 
> seconds and works fine from there.


Cura version and source?


> There are other AppImages but most either won't run or fail if writing.


We can save those for later.


> digiKam v8.2.0 cannot import from my camera because (and this is a swag) 
> it cannot get instant write perms. It can see everything in the camera, 
> but cannot download anything. And does not report any errors on the cli 
> when it fails.  It goes thru te motions, blinking all the lights, but 
> gimp cannot find the images it just went thru the motions of downloading.


digiKam version and source?


> Shotwell has the delay, and can import from the camera.


Shotwell version and source?


> Spectacle works in 5 secs, but kills plasma as it exits.


Spectacle version and source?


Debugging issues for any of the above programs is likely going to 
require duplicating your Debian configuration.   Are you prepared to 
provide these details?


As a alternative to, or in parallel with, duplicating your Debian, 
duplicating your apps, and debugging the combination stack, you might 
want to implement a work-around -- install a hypervisor, pick one 
application, create a virtual machine, install only enough Debian to 
support that application, install that application and nothing else, and 
use the application.  Repeat for each application.  (Of course, this 
presumes you can find a hypervisor that runs without issues on  your 
Debian.)


Another hypervisor idea -- do a fresh install of only enough Debian to 
support a hypervisor, install the hypervisor, then convert your existing 
Debian instance into a VM.


In any case, that NVMe PCIe SSD would be ideal for VM's.


David

[toc] | [prev] | [next] | [standalone]

#264813 — Re: raid10 is killing me, and applications that aren't willingtowaitfor it to respond

On 12/15/23 22:58, David Christensen wrote:
> On 12/15/23 18:23, gene heskett wrote:
>> I use the bleeding edge AppImage version of OpenSCAD, heavily, it has 
>> no such problems.  And no error outputs on the cli, it Just Works.
> 
> 
> Thank you for the reply.  :-)
> 
> 
> Do you mean the following?
> 
> https://openscad.org/downloads.html
> 
> OpenSCAD-2021.01-x86_64.AppImage.asc
No, thats quite old and slow, scroll down until you find the current 
linux AppImage, its much faster.
> 
> 
>> QIDISlicer gives these two errors instantly on launch from cli
>> Cannot register URI scheme wxfs more than once
>>
>> ** (qidi-slicer:24330): CRITICAL **: 12:29:20.900: Cannot register URI 
>> scheme memory more than once
>>
>> QIDISlicer has jillions of gtk2 things:
>> (qidi-slicer:24330): Gtk-CRITICAL **: 12:29:21.017: 
>> gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
>>
>> (qidi-slicer:24330): Gtk-CRITICAL **: 04:04:12.705: 
>> gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
>> including 50+ of the second, and many more gtk_gedget as it opens and 
>> works.  And I blame the packager since there is no more gtk2 in the 
>> debian repo's.
> 
> 
> Which QIDISlicer -- e.g. version?
> 
1.0.8 just released

> Where did you get it -- e.g. Debian package, AppImage, source tarball, 
> etc.?
 From qidi's site on github
> 
> 
>> Cura, latest 5.5.0 AppImage has a few warnings but opens in about 10 
>> seconds and works fine from there.
> 
> 
> Cura version and source?
>
 From the Ultimaker site link
UltiMaker-Cura-5.5.0-linux-X64.AppImage

> 
>> There are other AppImages but most either won't run or fail if writing.
> 
> 
> We can save those for later.
> 
> 
>> digiKam v8.2.0 cannot import from my camera because (and this is a 
>> swag) it cannot get instant write perms. It can see everything in the 
>> camera, but cannot download anything. And does not report any errors 
>> on the cli when it fails.  It goes thru te motions, blinking all the 
>> lights, but gimp cannot find the images it just went thru the motions 
>> of downloading.
> 
> 
> digiKam version and source?
digiKam-8.2.0-20230907T053317-x86-64.appimage, kde hosted
> 
> 
>> Shotwell has the delay, and can import from the camera.
> 
> 
> Shotwell version and source?
> 
Whatever is in bookworm repos for amd64/x86-64
> 
>> Spectacle works in 5 secs, but kills plasma as it exits.
> 
> 
> Spectacle version and source?

Whatever is in the bookworm repo's
> 
> Debugging issues for any of the above programs is likely going to 
> require duplicating your Debian configuration.   Are you prepared to 
> provide these details?
> 
> 
> As a alternative to, or in parallel with, duplicating your Debian, 
> duplicating your apps, and debugging the combination stack, you might 
> want to implement a work-around -- install a hypervisor, pick one 
> application, create a virtual machine, install only enough Debian to 
> support that application, install that application and nothing else, and 
> use the application.  Repeat for each application.  (Of course, this 
> presumes you can find a hypervisor that runs without issues on  your 
> Debian.)
> 
I'm only moderatly fam with that, and don't use it anymore, but 
octoprint uses the python version on the arm64's, but don't use 
octoprint since I found klipper. The python version is a bit of a pita 
to setup but works ok if I can remember the creation order. klipper is 
at home on the arms and doesn't need that complexity.  It is also much 
more capable of handling 3d printers. Point being that it is not 
installed or used on this machine, I've only used it on the arm sbc's.
> 
> Another hypervisor idea -- do a fresh install of only enough Debian to 
> support a hypervisor, install the hypervisor, then convert your existing 
> Debian instance into a VM.

Since qidislicer has not been rebased since buster, setting up a 
hypervisor and installing buster on it makes more sense but I'm pushing 
qidi to rebase it on a more modern release, preferably bookworm or even 
trixie. qidi has been very helpful so far but the request for a rebase 
has so far been somewhat miss-understood due to the nuances of the 
language barrier between me, an old English only Iowa farm kid, and the 
support person I'm messaging sometimes daily, who has some difficulty 
with English idioms & "slanguage" she did not learn in school. Otoh, 
this is by far the best Chinese support person I've ever dealt with.
The slicer itself is excellent and its failures have good work-arounds 
as the whole maryann uses a web interface, any browser can run the 
printer as long as its on the local net address block.

> 
> In any case, that NVMe PCIe SSD would be ideal for VM's.

No doubt but physically installing it is a major teardown and 
re-assembly of this machine, its located under several of the other 
cards in the machine.  And local access to it is limited, so I usually 
unplug everything and lug it all to a low table in the kitchen. This 
computer is a huge tower, weighs about 45 lbs and I'm 89 with a bad back.
Now I need to clarify a dhcpd.conf problem. But that is another post 
entirely.  Thank you a lot David.

> 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, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#264837 — Re: raid10 is killing me, and applications that aren't willingtowaitfor it to respond

On 12/16/23 07:06, gene heskett wrote:
> On 12/15/23 22:58, David Christensen wrote:
>> On 12/15/23 18:23, gene heskett wrote:
>>> I use the bleeding edge AppImage version of OpenSCAD, heavily, it has 
>>> no such problems.  And no error outputs on the cli, it Just Works.
>>
>>
>> Thank you for the reply.  :-)
>>
>>
>> Do you mean the following?
>>
>> https://openscad.org/downloads.html
>>
>> OpenSCAD-2021.01-x86_64.AppImage.asc
> No, thats quite old and slow, scroll down until you find the current 


On 12/15/23 20:00, David Christensen wrote:
 > *** correction *** OpenSCAD-2023.12.09.ai17758-x86_64.AppImage


> Now I need to clarify a dhcpd.conf problem. But that is another post 
> entirely.  Thank you a lot David.


Post when you want to continue with the disk I/O issues.


David

[toc] | [prev] | [next] | [standalone]

#264794 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

On 12/15/23 18:23, gene heskett wrote:
> I use the bleeding edge AppImage version of OpenSCAD, heavily, it has no 
> such problems.  And no error outputs on the cli, it Just Works.


Thank you for the reply.  :-)


Do you mean the following?

https://openscad.org/downloads.html

*** correction *** OpenSCAD-2023.12.09.ai17758-x86_64.AppImage


> QIDISlicer gives these two errors instantly on launch from cli
> Cannot register URI scheme wxfs more than once
> 
> ** (qidi-slicer:24330): CRITICAL **: 12:29:20.900: Cannot register URI 
> scheme memory more than once
> 
> QIDISlicer has jillions of gtk2 things:
> (qidi-slicer:24330): Gtk-CRITICAL **: 12:29:21.017: 
> gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
> 
> (qidi-slicer:24330): Gtk-CRITICAL **: 04:04:12.705: 
> gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton
> including 50+ of the second, and many more gtk_gedget as it opens and 
> works.  And I blame the packager since there is no more gtk2 in the 
> debian repo's.


Which QIDISlicer -- e.g. version?

Where did you get it -- e.g. Debian package, AppImage, source tarball, etc.?


> Cura, latest 5.5.0 AppImage has a few warnings but opens in about 10 
> seconds and works fine from there.


Cura version and source?


> There are other AppImages but most either won't run or fail if writing.


We can save those for later.


> digiKam v8.2.0 cannot import from my camera because (and this is a swag) 
> it cannot get instant write perms. It can see everything in the camera, 
> but cannot download anything. And does not report any errors on the cli 
> when it fails.  It goes thru te motions, blinking all the lights, but 
> gimp cannot find the images it just went thru the motions of downloading.


digiKam version and source?


> Shotwell has the delay, and can import from the camera.


Shotwell version and source?


> Spectacle works in 5 secs, but kills plasma as it exits.


Spectacle version and source?


Debugging issues for any of the above programs is likely going to 
require duplicating your Debian configuration.   Are you prepared to 
provide these details?


As a alternative to, or in parallel with, duplicating your Debian, 
duplicating your apps, and debugging the combination stack, you might 
want to implement a work-around -- install a hypervisor, pick one 
application, create a virtual machine, install only enough Debian to 
support that application, install that application and nothing else, and 
use the application.  Repeat for each application.  (Of course, this 
presumes you can find a hypervisor that runs without issues on  your 
Debian.)


Another hypervisor idea -- do a fresh install of only enough Debian to 
support a hypervisor, install the hypervisor, then convert your existing 
Debian instance into a VM.


In any case, that NVMe PCIe SSD would be ideal for VM's.


David

[toc] | [prev] | [next] | [standalone]

#264795 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

I had to go to Wikipedia to understand the context of the discussion. I 
did read all the posted emails in the thread.

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

[toc] | [prev] | [next] | [standalone]

#264797 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

On Fri, Dec 15, 2023 at 11:05:41PM -0500, Matt wrote:
> I had to go to Wikipedia to understand the context of the discussion. I did
> read all the posted emails in the thread.
> 
> https://en.wikipedia.org/wiki/RAID

Knowing what RAID is... is good.  But ultimately, the main takeaway from
this thread should be that when diagnosing a problem, you may sometimes
discover that the root of the problem is different from what you thought.

In Gene's case, the problem (long startup time of some applications) does
not appear to be related to his disks, but rather, to something in the
desktop environment or its underlying services.

[toc] | [prev] | [next] | [standalone]

#264798 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

Perhaps that is why I run DWM rather than GNOME on this T60 Thinkpad. :p

On 12/15/23 23:23, Greg Wooledge wrote:
> On Fri, Dec 15, 2023 at 11:05:41PM -0500, Matt wrote:
>> I had to go to Wikipedia to understand the context of the discussion. I did
>> read all the posted emails in the thread.
>>
>> https://en.wikipedia.org/wiki/RAID
> Knowing what RAID is... is good.  But ultimately, the main takeaway from
> this thread should be that when diagnosing a problem, you may sometimes
> discover that the root of the problem is different from what you thought.
>
> In Gene's case, the problem (long startup time of some applications) does
> not appear to be related to his disks, but rather, to something in the
> desktop environment or its underlying services.
>

[toc] | [prev] | [next] | [standalone]

#264802 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

Greg Wooledge <greg@wooledge.org> writes:

> In Gene's case, the problem (long startup time of some applications) does
> not appear to be related to his disks, but rather, to something in the
> desktop environment or its underlying services.

But isn't it fairly easy to try another desktop environment to eliminate
this as a cause? Or has this already been done? 

For the RAID stuff, I think Gene said earlier he could try putting his
home directory on an ordinary drive? To eliminate the RAID as a problem.

[toc] | [prev] | [next] | [standalone]

#264832 — Re: raid10 is killing me, and applications that aren't willing towaitfor it to respond

On 12/16/23 00:26, Anssi Saari wrote:
> Greg Wooledge <greg@wooledge.org> writes:
> 
>> In Gene's case, the problem (long startup time of some applications) does
>> not appear to be related to his disks, but rather, to something in the
>> desktop environment or its underlying services.
> 
> But isn't it fairly easy to try another desktop environment to eliminate
> this as a cause? Or has this already been done?


AIUI Gene already has several desktop environments installed on the same 
computer.  This has led to the theory that those multiple desktop 
environments are clashing in some way that affects disk I/O for certain 
applications.


> For the RAID stuff, I think Gene said earlier he could try putting his
> home directory on an ordinary drive? To eliminate the RAID as a problem.


Gene and various readers have proposed more than a few trouble-shooting 
strategies, possible solutions, and work-arounds, including the above. 
It is up to Gene to decide if, what, where, when, and how he is going to 
proceed.


David

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web