1 |
Dr Rainer Woitok wrote: |
2 |
> |
3 |
> Well, it's been quite a while, due to my being almost permanently con- |
4 |
> fronted with more pressing tasks ... :-( |
5 |
> |
6 |
> To sum up my experience with my new 128 GB Philips USB 3.0 sticks: while |
7 |
> the Philips sticks are significantly faster for reading operations than |
8 |
> my old 64 GB Verbatim ones (probably USB 2.0), writing operations to the |
9 |
> Philips sticks are unbearably slow, regardless of whether I created a |
10 |
> normal unencrypted NTFS filesystem on them or an encrypted NTFS filesys- |
11 |
> tem using VeraCrypt. Writing to the USB stick while at the same time |
12 |
> reading from it in a different terminal window caused commands like "cd" |
13 |
> or "ls" to simply stall. Thus while running |
14 |
> |
15 |
> $ cp --preserve=timestamps -ru $source_dir . |
16 |
> |
17 |
> in one terminal window, I ran |
18 |
> |
19 |
> $ while true |
20 |
> > do n=$(ps -ef|g 'cp --preserve'|g -v grep) |
21 |
> > if [[ "$n" = "${o-}" ]] |
22 |
> > then sleep 10 |
23 |
> > else o="$n" |
24 |
> > echo "$n" |
25 |
> > fi |
26 |
> > done |
27 |
> |
28 |
> in another, to get the wall clock times when copying a new file began. |
29 |
> That way I found that copying a 30 MB file took about 40 minutes. |
30 |
> |
31 |
> So what are my options? |
32 |
> |
33 |
> - Stay away from Philips USB 3.0 sticks? |
34 |
> |
35 |
> - Stay away from Philips USB sticks in general? |
36 |
> |
37 |
> - Stay away from USB 3.0 sticks in general? |
38 |
> |
39 |
> - Stay away from Filesystem in User Space using a non-stable 5.10 or |
40 |
> 5.11 kernel (currently I'm using stable 5.4.97)? |
41 |
> |
42 |
> - Stay away from Gentoo? |
43 |
> |
44 |
> - Stay away from Linux in general and go back to OTOS (aka the Only |
45 |
> True Operating System aka Windoze)? |
46 |
> |
47 |
> - ...? |
48 |
> |
49 |
> Any ideas and comments welcome ... |
50 |
> |
51 |
> Sincerely, |
52 |
> Rainer |
53 |
> |
54 |
> |
55 |
|
56 |
|
57 |
Have you tried using dd to test the speed? It doesn't even need a file |
58 |
system as it writes directly to the device. I've done this in the past |
59 |
and it tells if it is a file system issue or a hardware issue. One |
60 |
thing here, it will destroy ANY and ALL data on it if you let it run |
61 |
until it finishes. Make sure you have nothing you want to save on it |
62 |
when doing this. I might add, I like this over rsync --progress because |
63 |
it doesn't have a file system in the middle. |
64 |
|
65 |
Commands I use to test this. |
66 |
|
67 |
dd if=/dev/zero of=/dev/sd bs=4k conv=notrunc oflag=direct #disables cache |
68 |
|
69 |
Don't forget to complete the disk device in the "of=" section and you |
70 |
can leave off the comment as well when typing it in. You may also want |
71 |
to adjust the other settings or leave out some to test things. See if |
72 |
you can figure out a way to tweek it a bit. Sometimes you can add those |
73 |
to the mount options to make it work better, so I've read anyway. |
74 |
|
75 |
To monitor the speed, I found this years ago and it still worked a few |
76 |
months ago when I was testing a stick that was giving me problems. |
77 |
Turned out, the stick was dying a slow death. The dd test finished it, |
78 |
with errors. |
79 |
|
80 |
watch -n 10 kill -USR1 <pid of process> |
81 |
|
82 |
I use Konsole here which has tabs but you may use something similar that |
83 |
will work just as well. I start the dd command in one tab, then go to |
84 |
other tab and find the process number for dd there with ps and grep. I |
85 |
then use the above and replace "<pid of process>" with the number, leave |
86 |
out the <> as well, just the number itself. When you go to the tab |
87 |
where dd is running, it updates about every ten seconds with speed and |
88 |
other info. I've found it normal to start out fast and then slow down |
89 |
as it goes. Since it has no moving parts, no clue why it does that. |
90 |
|
91 |
Someone else may see this and have a much better method but that has |
92 |
worked for me in the past. As we know, some USB stick and other memory |
93 |
type cards can get fussy or go bad. |
94 |
|
95 |
Hope that helps or at least gives some ideas. |
96 |
|
97 |
Dale |
98 |
|
99 |
:-) :-) |
100 |
|
101 |
P. S. I just copy what folks post, I don't claim to understand the |
102 |
inner workings of this. LOL I do know, it destroys data tho. Always |
103 |
be careful with dd and if and 0. |