On Tue, 2023-10-31 at 00:39 +1100, fed...@eyal.emu.id.au wrote:
> > Possibly. A good test would be to repeat the experiment but with a
> > different target destination, such as /dev/null. This would
> > indicate
> > whether the problem is with reading or with writing.
>
> Yes, done that. Copying t
Linux is notoriously slow for large copies over usb3. The reading
I've done on it seems to suggest that it has to do with how buffering
in RAM works. There doesn't seem to be an elegant solution. Some
solutions posted are:
1) Make sure the external drive is ext4 or other linux-friendly format
On 30/10/2023 23.20, Patrick O'Callaghan wrote:
On Mon, 2023-10-30 at 22:58 +1100, fed...@eyal.emu.id.au wrote:
On 30/10/2023 22.41, Patrick O'Callaghan wrote:
On Mon, 2023-10-30 at 22:35 +1100, fed...@eyal.emu.id.au wrote:
On 30/10/2023 21.40, Patrick O'Callaghan wrote:
On Mon, 2023-10-30 at
On Mon, 2023-10-30 at 22:58 +1100, fed...@eyal.emu.id.au wrote:
> On 30/10/2023 22.41, Patrick O'Callaghan wrote:
> > On Mon, 2023-10-30 at 22:35 +1100, fed...@eyal.emu.id.au wrote:
> > > On 30/10/2023 21.40, Patrick O'Callaghan wrote:
> > > > On Mon, 2023-10-30 at 18:22 +1100, fed...@eyal.emu.id.a
On 30/10/2023 22.53, Iosif Fettich wrote:
Next, I will do a plain 'cp -a' between the original source (sdh on /sata) and
target(md127 on /data1) to see how it goes.
Do the files/directories that you want to copy change frequently...?
Maybe you can isolate your sources into groups that wouldn't
On 30/10/2023 22.41, Patrick O'Callaghan wrote:
On Mon, 2023-10-30 at 22:35 +1100, fed...@eyal.emu.id.au wrote:
On 30/10/2023 21.40, Patrick O'Callaghan wrote:
On Mon, 2023-10-30 at 18:22 +1100, fed...@eyal.emu.id.au wrote:
Should I blame rsync (or the way I use it)?
Next, I will do a plain '
Next, I will do a plain 'cp -a' between the original source (sdh on /sata) and
target(md127 on /data1) to see how it goes.
Do the files/directories that you want to copy change frequently...?
Maybe you can isolate your sources into groups that wouldn't change during one
rsync run?
I think to h
On Mon, 2023-10-30 at 22:35 +1100, fed...@eyal.emu.id.au wrote:
> On 30/10/2023 21.40, Patrick O'Callaghan wrote:
> > On Mon, 2023-10-30 at 18:22 +1100, fed...@eyal.emu.id.au wrote:
> > > Should I blame rsync (or the way I use it)?
> > >
> > > Next, I will do a plain 'cp -a' between the original s
On 30/10/2023 21.40, Patrick O'Callaghan wrote:
On Mon, 2023-10-30 at 18:22 +1100, fed...@eyal.emu.id.au wrote:
Should I blame rsync (or the way I use it)?
Next, I will do a plain 'cp -a' between the original source (sdh on
/sata) and target(md127 on /data1) to see how it goes.
If you say how
On Mon, 2023-10-30 at 18:22 +1100, fed...@eyal.emu.id.au wrote:
> Should I blame rsync (or the way I use it)?
>
> Next, I will do a plain 'cp -a' between the original source (sdh on
> /sata) and target(md127 on /data1) to see how it goes.
If you say how you use it, someone might be able to answer
On 30/10/2023 13.42, fed...@eyal.emu.id.au wrote:
F38
Linux e7.eyal.emu.id.au 6.5.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 20
15:53:48 UTC 2023 x86_64 GNU/Linux
I am looking at issues with my system which is ATM degraded (6/7 raid6 devices).
I am waiting for a replacement disk from seag
F38
Linux e7.eyal.emu.id.au 6.5.8-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 20
15:53:48 UTC 2023 x86_64 GNU/Linux
I am looking at issues with my system which is ATM degraded (6/7 raid6 devices).
I am waiting for a replacement disk from seagate RMA.
Unrelated, I am trying to copy a director
12 matches
Mail list logo
