Dr Rainer Woitok wrote:
>
> Well, it's been quite a while, due to my being almost permanently con-
> fronted with more pressing tasks ... :-(
>
> To sum up my experience with my new 128 GB Philips USB 3.0 sticks: while
> the Philips sticks are significantly faster for reading operations than
> my old 64 GB Verbatim ones (probably USB 2.0), writing operations to the
> Philips sticks are unbearably slow, regardless of whether I created a
> normal unencrypted NTFS filesystem on them or an encrypted NTFS filesys-
> tem using VeraCrypt. Writing to the USB stick while at the same time
> reading from it in a different terminal window caused commands like "cd"
> or "ls" to simply stall. Thus while running
>
> $ cp --preserve=timestamps -ru $source_dir .
>
> in one terminal window, I ran
>
> $ while true
> > do n=$(ps -ef|g 'cp --preserve'|g -v grep)
> > if [[ "$n" = "${o-}" ]]
> > then sleep 10
> > else o="$n"
> > echo "$n"
> > fi
> > done
>
> in another, to get the wall clock times when copying a new file began.
> That way I found that copying a 30 MB file took about 40 minutes.
>
> So what are my options?
>
> - Stay away from Philips USB 3.0 sticks?
>
> - Stay away from Philips USB sticks in general?
>
> - Stay away from USB 3.0 sticks in general?
>
> - Stay away from Filesystem in User Space using a non-stable 5.10 or
> 5.11 kernel (currently I'm using stable 5.4.97)?
>
> - Stay away from Gentoo?
>
> - Stay away from Linux in general and go back to OTOS (aka the Only
> True Operating System aka Windoze)?
>
> - ...?
>
> Any ideas and comments welcome ...
>
> Sincerely,
> Rainer
>
>
Have you tried using dd to test the speed? It doesn't even need a file
system as it writes directly to the device. I've done this in the past
and it tells if it is a file system issue or a hardware issue. One
thing here, it will destroy ANY and ALL data on it if you let it run
until it finishes. Make sure you have nothing you want to save on it
when doing this. I might add, I like this over rsync --progress because
it doesn't have a file system in the middle.
Commands I use to test this.
dd if=/dev/zero of=/dev/sd bs=4k conv=notrunc oflag=direct #disables cache
Don't forget to complete the disk device in the "of=" section and you
can leave off the comment as well when typing it in. You may also want
to adjust the other settings or leave out some to test things. See if
you can figure out a way to tweek it a bit. Sometimes you can add those
to the mount options to make it work better, so I've read anyway.
To monitor the speed, I found this years ago and it still worked a few
months ago when I was testing a stick that was giving me problems.
Turned out, the stick was dying a slow death. The dd test finished it,
with errors.
watch -n 10 kill -USR1 <pid of process>
I use Konsole here which has tabs but you may use something similar that
will work just as well. I start the dd command in one tab, then go to
other tab and find the process number for dd there with ps and grep. I
then use the above and replace "<pid of process>" with the number, leave
out the <> as well, just the number itself. When you go to the tab
where dd is running, it updates about every ten seconds with speed and
other info. I've found it normal to start out fast and then slow down
as it goes. Since it has no moving parts, no clue why it does that.
Someone else may see this and have a much better method but that has
worked for me in the past. As we know, some USB stick and other memory
type cards can get fussy or go bad.
Hope that helps or at least gives some ideas.
Dale
:-) :-)
P. S. I just copy what folks post, I don't claim to understand the
inner workings of this. LOL I do know, it destroys data tho. Always
be careful with dd and if and 0.
