Hi,

Raspberry Pi4 RISC OS 5.28

As usual, I was backing up the Pi to my external hardisc using Dave
Pilling / Chris Johnson's !SyncDiscs.

Every now & again I got "No Hardwareat this device ID." Clicking abort
or retry allowed the app to carry on. Had a brief look at the backup & it
looks fine. Verified my RISC OS format backup disc and it reported OK.
Anyone ever seen this phenomenon?

--
Chris Newman

In article <5964278749cvjazz@waitrose.com>,
Chris Newman <cvjazz@waitrose.com> wrote:
> Hi,

> Raspberry Pi4 RISC OS 5.28

> As usual, I was backing up the Pi to my external hardisc using Dave
> Pilling / Chris Johnson's !SyncDiscs.

> Every now & again I got "No Hardwareat this device ID." Clicking abort
> or retry allowed the app to carry on. Had a brief look at the backup &
> it looks fine. Verified my RISC OS format backup disc and it reported
> OK. Anyone ever seen this phenomenon?

Yes, exactly as you describe.

--
_____________________________________________________________________

Brian Jordan
RISC OS 5.28 (19-Oct-20) on Raspberry Pi
_____________________________________________________________________

In article <5964278749cvjazz@waitrose.com>,
Chris Newman <cvjazz@waitrose.com> wrote:
> Hi,

> Raspberry Pi4 RISC OS 5.28

> As usual, I was backing up the Pi to my external hardisc using Dave
> Pilling / Chris Johnson's !SyncDiscs.

> Every now & again I got "No Hardwareat this device ID." Clicking
> abort or retry allowed the app to carry on. Had a brief look at the
> backup & it looks fine. Verified my RISC OS format backup disc and
> it reported OK. Anyone ever seen this phenomenon?

That error message is not generated by !SyncDiscs, but by the OS. I
assume your external drive is connected via USB. It could be that the
drive is periodically becoming invisible for short periods.

When I used external drives (SSD) with the BeagleBoard and PandaES in
the past I saw something similar when the usb drive disappeared. I
thought it was due to either/or/and RISC OS usb stack problems and
power supply gliches when the drive was working hard.

--
Chris Johnson

In article <59642bb9a8chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:
> In article <5964278749cvjazz@waitrose.com>,
> Chris Newman <cvjazz@waitrose.com> wrote:
> > Hi,

> > Raspberry Pi4 RISC OS 5.28

> > As usual, I was backing up the Pi to my external hardisc using Dave
> > Pilling / Chris Johnson's !SyncDiscs.

> > Every now & again I got "No Hardwareat this device ID." Clicking
> > abort or retry allowed the app to carry on. Had a brief look at the
> > backup & it looks fine. Verified my RISC OS format backup disc and
> > it reported OK. Anyone ever seen this phenomenon?

> That error message is not generated by !SyncDiscs, but by the OS. I
> assume your external drive is connected via USB. It could be that the
> drive is periodically becoming invisible for short periods.

Correct. Thanks for explaining.

> When I used external drives (SSD) with the BeagleBoard and PandaES in
> the past I saw something similar when the usb drive disappeared. I
> thought it was due to either/or/and RISC OS usb stack problems and
> power supply gliches when the drive was working hard.

So that begs the questions:-

1) What's the best choice to continue "Retry" ?

2) Will I have missed backing up some data.

--
Chris Newman

In article <5964434c5fcvjazz@waitrose.com>,
Chris Newman <cvjazz@waitrose.com> wrote:
> So that begs the questions:-

> 1) What's the best choice to continue "Retry" ?

> 2) Will I have missed backing up some data.

Abort will do just that to the filer action (e.g. copy), so that
particular action will be terminated. Retry will attempt to do the
action again, so any sync action will ultimately complete. The
question will be whether the retry attempt will be allowed by the
filer action.

A final check would be to do a 'Compare' on the two directories after
the sync has allegedly completed. This would show up if there were
any differences remaining.

Is the use of SyncDiscs the only intensive activity the external
drive would be subjected to? When I had similar sorts of problems it
was not necessarily SyncDiscs, but any file system intensive
operations that could stall. I also found it affected some brands of
SSD (or the corresponding usb-SATA interface or powered hub) much
more than others, which made me wonder about power supply effects.

--
Chris Johnson

News <chrisjohnson@spamcop.net> wrote:
> That error message is not generated by !SyncDiscs, but by the OS. I
> assume your external drive is connected via USB. It could be that the
> drive is periodically becoming invisible for short periods.
>
> When I used external drives (SSD) with the BeagleBoard and PandaES in
> the past I saw something similar when the usb drive disappeared. I
> thought it was due to either/or/and RISC OS usb stack problems and
> power supply gliches when the drive was working hard.

Just a random guess, but sometimes external HDD go to sleep and spin down to
save power. They then take a long time to spin up again when accessed, and
any accesses stall until they're ready.

It wouldn't be related to some effect like this, would it?

Theo

In article <Oeh*hw1sy@news.chiark.greenend.org.uk>,
Theo <theom+news@chiark.greenend.org.uk> wrote:
> Just a random guess, but sometimes external HDD go to sleep and
> spin down to save power. They then take a long time to spin up
> again when accessed, and any accesses stall until they're ready.

> It wouldn't be related to some effect like this, would it?

This could certainly occur in general usage, and I am sure it does.
My NAS certainly spins the drives down after some inactivity, and
there is then a pause of a few seconds for the drive to come up again
when it is accessed later. However, when SyncDiscs is running then it
is continuously accessing the file catalogue info for the file/dir
details, even if almost all the files do not need updating. I do not
think the drive would spin down under these circumstances.

In my case, all the drives were SSD, hence no actual spin up/spin
down. Drive operation would just stop, often in the middle of a file
operation (filer action would raise an error box), and the file name
under the drive on the iconbar would revert to :5 or whatever until
the drive icon was clicked on and normal action was restored. I am
not saying that is what is happening here, only that there have often
been issues with usb hard drives when worked hard.

--
Chris Johnson

In article <5964526d07chrisjohnson@spamcop.net>,
News <chrisjohnson@spamcop.net> wrote:
> In article <Oeh*hw1sy@news.chiark.greenend.org.uk>,
> Theo <theom+news@chiark.greenend.org.uk> wrote:
> > Just a random guess, but sometimes external HDD go to sleep and
> > spin down to save power. They then take a long time to spin up
> > again when accessed, and any accesses stall until they're ready.

> > It wouldn't be related to some effect like this, would it?

> This could certainly occur in general usage, and I am sure it does.
> My NAS certainly spins the drives down after some inactivity, and
> there is then a pause of a few seconds for the drive to come up again
> when it is accessed later. However, when SyncDiscs is running then it
> is continuously accessing the file catalogue info for the file/dir
> details, even if almost all the files do not need updating. I do not
> think the drive would spin down under these circumstances.

> In my case, all the drives were SSD, hence no actual spin up/spin
> down. Drive operation would just stop, often in the middle of a file
> operation (filer action would raise an error box), and the file name
> under the drive on the iconbar would revert to :5 or whatever until
> the drive icon was clicked on and normal action was restored. I am
> not saying that is what is happening here, only that there have often
> been issues with usb hard drives when worked hard.

I'd done lots of previous backups with the same disc & this is the first
time I've encountered this effect.

--
Chris Newman