DUET3 + PI: DWC "hang" or sluggish? /etc/fstab?



  • I added an automount CIFS filesystem to /etc/fstab (to enable backups of the entire Pi SD). If the automount failed and was retrying in the background, this would cause long delay in random DWC responses, and cause a very consistent delay in the restart after an "Emergency Stop"

    Commenting that out of /etc/fstab and rebooting (I know... I know...) made everything snappy again.

    So, I will put it back in without automount, and mount it when I need it for backups.



  • When you mount it manually and it succeeds is the DWC (actually the Duet Web Server) still slow or only if it fails and is retrying?



  • @gtj0 said in DUET3 + PI: DWC "hang" or sluggish? /etc/fstab?:

    When you mount it manually and it succeeds is the DWC (actually the Duet Web Server) still slow or only if it fails and is retrying?

    Haven't tried that yet. Will report here when I do.



  • Yeah. The web server may be trying to do something dumb like scan the filesystems when a request is made. It may not even be in @chrishamm's code. It may be in Microsoft's.



  • OK, been doing some additional testing. I can detect no slowness with the file system in /etc/fstab and 'noauto'. I can detect no slowness when I intentionally break security so that it doesn't mount. I can detect no slowness when it mounts.

    The only circumstance where I clearly see delays is when 'auto' is set in /etc/fstab, yet the mount fails and periodically retries in the background.

    There may be other effects; some of this stuff is a little hard to pin down.



  • Try combinations of the following mount options...

    • soft
    • x-systemd.mount-timeout=500ms
    • x-systemd.device-timeout=500ms

    Experiment with the times to see if you can arrive at a value that works.



  • @gtj0 said in DUET3 + PI: DWC "hang" or sluggish? /etc/fstab?:

    Try combinations of the following mount options...

    • soft
    • x-systemd.mount-timeout=500ms
    • x-systemd.device-timeout=500ms

    Experiment with the times to see if you can arrive at a value that works.

    To be clear, many different ways to both have this mount and no delays. The only clear failure at this point is 'auto' (the default) with

    //USDNLW11/RPiBackups /RPiBackups cifs user=pi,password=xxxxx,x-systemd.automount 0 0
    

    And the Windows machine was refusing the connection.

    Note this is not that great an fstab entry... among other thigns, it really should have '_netdev'.

    But, again, back to delays: Only the fstab entry above, which fails over and over because windows was refusing it, causes the perceptible delays in DWC.



  • Yeah I was trying to see if setting a shorter timeout wouldn't hang things. I can try more stuff tomorrow. My printer is in pieces today.



  • At this point, I actually cannot reproduce the failure. I'll keep trying, and if I do, I will try the timeouts.


Log in to reply