USB flash disk/Kingston/DataTraveler microDuo/64 GB/rychlost/Kychot

Tato stránka je součástí projektu:
Flash paměti
Příslušnost: všeobecná

USB flash disk Kingston DataTraveler microDuo 64 GB - problémy s rychlostí

Kychot

2015-07-22 koupě a problém s kopírováním souborů

Tuto USB paměť jsem koupil dne 2015-07-22 u CZC. Ten samý večer jsem na ní chtěl uložit nějaké fotografie, ale přenos byl tak pomalý, že se tento flash disk ukázal být prakticky nepoužitelným.

Postup:

Zasunutí paměti do USB/A portu v notebooku HP EliteBook 8530w/Kychot, na kterém běží Ubuntu
1. Velikost disku se jeví jako 63 GB
2. Rozdělení disku na dvě partition:
  1. 8 GB naformátováno jako FAT
  2. 55 GB naformátováno jako NTFS (a to z toho důvodu, že tento filesystem lze snadno namontovat jak na Android, tak na Windoze)
3. Z FAT partition vytvořím bootovací disk pro Xubuntu (z obrazu .iso)
4. Pomocí mc (Midnight Commander) do NTFS partiton kopíruji adresáře s fotografiemi
5. mc hlásí kopírování rychlostí cca 500 KB/s, takže zaplnění cca čtvrtiny disku by trvalo asi 9 hodin; tato rychlost v průběhu doby neustále klesá, nakonec se překopírování jednoho souboru o velikosti několika MB táhne už několik minut. mc pomalu zamrzá
6. příkaz sync už nemá žádnou odezvu
7. je problém disk odpojit
Poté zasunu disk do micro USB portu na Google Nexus 7/Kychot, kde ho připojím prostřednictvím aplikace Open Total Commander s pluginem Paragon_NTFS (Paragon non root mounter)
1. nahraji na něj fotografie z adresáře DCIM o velikost .... . Kopírování trvá cca 6 minut
2. Disk vysunu z micro USB portu

Problém se čtením flešky v jiném netbooku

Disk zasunu do USB/A portu v netbooku Mivvy m310, kde běží Xubuntu 14.04 LTS
1. Přimontuje se pouze: /dev/sdc1 on /media/petr/King8GB type vfat
2. Pokus o přimontování druhé partition se nedaří, hláška:

Nepodařilo se připojit "King55GB".
Error mounting /dev/sdc2 at /media/petr/King55GB: Command-line `mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177" "/dev/sdc2" "/media/petr/King55GB"' exited with non-zero exit status 13: $MFTMirr does not match $MFT (record 0).
Failed to mount '/dev/sdc2': Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.
.

2015-07-23 reparace filesystému NTFS

Gůglím:

http://askubuntu.com (2014-07-29): Will I be able to use my NTFS data partition in Ubuntu? 6: Others have posted good information; however, there's one other critical detail: Ubuntu lacks a useful NTFS repair utility. Filesystems occasionally become damaged. Power outages, bugs, system crashes, and other conditions can cause this to happen. When Ubuntu encounters a damaged NTFS volume, Ubuntu will refuse to mount it. Thus, on an Ubuntu-only system, using NTFS on an internal disk is a problem waiting to happen. As soon as that NTFS volume becomes damaged (and it will), you'll have to move the disk to another computer or use a Windows emergency disk to repair it. Either action is a hassle and even creates new risks.
https://help.ubuntu.com
- (2014-11-16): MountingWindowsPartitions
- (2014-10-14): ntfs-3g (previously also ntfsprogs) - NTFS filesystem

# ntfsfix /dev/sdc2

Mounting volume... $MFTMirr does not match $MFT (record 0).
FAILED
Attempting to correct errors... 
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 0...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdc2 was processed successfully.

Poté už to jde normálně přimontovat.

DESCRIPTION

      ntfsfix  is  a utility that fixes some common NTFS problems.  ntfsfix is NOT a Linux version of chkdsk.  It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows.

scrounge-ntfs balík: "scrounge-ntfs is a utility that can rescue data from corrupted NTFS partitions. It writes the files retrieved to another working file system. Certain information about the partition needs to be known in advance."

 scrounge-ntfs -l /dev/sdc
    Start Sector    End Sector      Cluster Size    MFT Offset    
==================================================================

Drive: /dev/sdc
    63              15626985        
    15627048        107288280       8               32

Otázkou k diskusi zůstává, jestli je NTFS skutečně tím pravým filesystémem pro sdílení dat mezi Linuxem, Androidem a Win.

2015-07-25 – podobné případy

Gůglím:

ubuntuforums.org (2015-04-15): Slow data transfer to flash drive Xubuntu 14.04
- ckrles: ... I'm running Xubuntu 14.04 and I have noticed that data transfer to flash drives is extremely slow on both my laptop and desktop.
- ckrles: ... They are formatted in fat32 where the speed is 1-2 mb/s, but if I format them in ntfs it starts at 9 mb/s, it keeps in 4-5 mb/s for a while and then drops to 2 mb/s. I haven't tried ext4 because there are some devices which do not recognise this format when I plug the flash drive in. – tak to je hodně podobné tomu mému případu

Test rychlosti (dd & hdparm )

shellhacks (2014-08-15): HowTo : TEST Read/Write Speed of a Hard Disk in Linux
Werner Fischer (2015-07-08): Linux I/O Performance Tests using dd

Princip měření

Rychlost zápisu:

# sync; time dd if=/dev/zero of=/tmp/100MB bs=1M count=100; time sync

Rychlost čtení:

# /sbin/sysctl -w vm.drop_caches=3
# sync; time dd if=tmp100MB of=/dev/null bs=1M count=100; time sync

Zkouším také zvýšit prioritu, ale bez velkého efektu:

# sync; nice -n -15 dd if=/dev/zero of=tmp100MB bs=1M count=100; nice -n -15 sync
# sync; nice --adjustment=-15 dd if=/dev/zero of=tmp100MB bs=1M count=100; nice --adjustment=-15 sync

Další metodou je příkaz hdparm:

# hdparm -Tt <device>

Poslední zkouškou pro čtení a zápis je běžné kopírování souboru příkazem cp

# time cp tmp100MB tmp100MB-kopie

Nejdříve vyzkoušíme metodu na HDD a na flash disku, který normálně funguje:

HDD

filesystem: ext3:

Výsledek měření: 85–100 MB/s Čtení: 50 MB/s

Pomocí hdparm:

# hdparm -Tt <device>

/dev/sda5:
 Timing cached reads:   1030 MB in  2.00 seconds = 515.20 MB/sec
 Timing buffered disk reads: 160 MB in  3.00 seconds =  53.26 MB/sec

/dev/sda4:
 Timing cached reads:   1006 MB in  2.00 seconds = 502.57 MB/sec
 Timing buffered disk reads: 104 MB in  3.06 seconds =  34.02 MB/sec
root@mi:/media/petr/8789-1BDC# hdparm -Tt /dev/sda2

/dev/sda2:
 Timing cached reads:   1036 MB in  2.00 seconds = 518.19 MB/sec
 Timing buffered disk reads: 154 MB in  3.01 seconds =  51.13 MB/sec

 # time cp -p tmp100MB tmp100MB-kopie

real    0m3.683s
user    0m0.016s
sys     0m0.776s

což dá cca 27 MB/s

Kingston DT Micro 16 GB

Jedná se o flash disk, který používám již řadu let ba problémů. Na něm vyzkouším metody měření a výsledky pro porovnání.

partition 5 (2.6 GB) vfat: 14, 14, 7, 9, 6, 12, 7, 10, 14, 7, 3, 14, 6, 5, 11, 6 MB/s (velké rozdíly ve výsledcích pokusů)
partition 1 (13 GB) vfat: 843 kB/s, 1, 1 MB/s, (!!)

Zápis na větší partition je 10x pomalejší! Jak to??

Rychlost čtení:

partition 5: 16 MB/s
partition 1: 8.4 MB/s (rychlost čtení nekolísá, na rozdíl or rychlosti zápisu)

Rychlost čtení z menší partition je 2x rychlejší než z velké!

# hdparm -Tt <device>

/dev/sdc1:

Timing cached reads:   970 MB in  2.00 seconds = 485.09 MB/sec
Timing buffered disk reads:  44 MB in  3.03 seconds =  14.53 MB/sec

root@mi:/tmp# hdparm -Tt /dev/sdc1

/dev/sdc5:

Timing cached reads:   996 MB in  2.00 seconds = 497.77 MB/sec
Timing buffered disk reads:  46 MB in  3.13 seconds =  14.71 MB/sec

Tady jsou výsledky u obou partition stejné.

Běžné kopírování:

Malá partition 2.6 GB:

# time cp /tmp/tmp100MB tmp100MB-kopie

real    0m18.452s
user    0m0.016s
sys     0m0.816s

real    0m26.544s
user    0m0.000s
sys     0m1.184s

real    0m16.626s
user    0m0.008s
sys     0m0.884s

Výsledky varírují mezi 3.7 až 6 MB/s.

Velká partition 13 GB:

real    1m27.060s
user    0m0.012s
sys     0m0.852s

real    0m21.062s
user    0m0.000s
sys     0m0.772s

real    0m36.873s
user    0m0.008s
sys     0m1.300s

Výsledky 1.1 až 4.7 MB/s

Test FIO

Binary Lane (2015-01-11): How to benchmark disk I/O

Tady se píše, že tradiční test pomocí dd raději nepoužívat.

Instalace FIO

yum install -y make gcc libaio-devel || ( apt-get update && apt-get install -y make gcc libaio-dev  </dev/null )
wget https://github.com/Crowd9/Benchmark/raw/master/fio-2.0.9.tar.gz ; tar xf fio*
cd fio*
make

make skončí s hláškou

os/os.h:45:20: fatal error: libaio.h: Adresář nebo soubor neexistuje

Tak tedy:

apt-get install libaio-dev
make

Během kompilace 1 warning:

CC options.o
options.c: In function ‘fio_keywords_init’:
options.c:2338:2: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uintptr_t’ [-Wformat=]
  sprintf(buf, "%lu", page_size);

Zkusím test na HDD se souborem 100 MB (1G by trvalo hrozně dlouho), kombinován 1x zápis a 3x čtení souboru:

./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=100M --readwrite=randrw --rwmixread=75

Výsledek:

test: (g=0): rw=randrw, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
Jobs: 1 (f=1): [m] [100.0% done] [854K/279K /s] [213 /69  iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=7478: Sat Jul 25 10:16:29 2015
  read : io=76568KB, bw=494407 B/s, iops=120 , runt=158585msec
  write: io=25832KB, bw=166799 B/s, iops=40 , runt=158585msec
  cpu          : usr=0.61%, sys=2.57%, ctx=24852, majf=0, minf=0
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.8%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=19142/w=0/d=6458, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=76568KB, aggrb=482KB/s, minb=482KB/s, maxb=482KB/s, mint=158585msec, maxt=158585msec
  WRITE: io=25832KB, aggrb=162KB/s, minb=162KB/s, maxb=162KB/s, mint=158585msec, maxt=158585msec

Disk stats (read/write):
  sda: ios=18812/6560, merge=244/208, ticks=7523884/2705976, in_queue=10237812, util=100.00%

Jenom zápis (random write):

./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=100M --readwrite=randwrite

test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=64
fio-2.0.9
Starting 1 process
Jobs: 1 (f=1): [w] [98.6% done] [0K/2107K /s] [0 /526  iops] [eta 00m:01s]
test: (groupid=0, jobs=1): err= 0: pid=7539: Sat Jul 25 10:29:15 2015
  write: io=102400KB, bw=1409.3KB/s, iops=352 , runt= 72661msec
  cpu          : usr=1.39%, sys=5.00%, ctx=25216, majf=0, minf=0
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.8%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=0/w=0/d=25600, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=102400KB, aggrb=1409KB/s, minb=1409KB/s, maxb=1409KB/s, mint=72661msec, maxt=72661msec

Disk stats (read/write):
  sda: ios=0/25120, merge=0/516, ticks=0/4761164, in_queue=4766356, util=100.00%

Takže výsledek 1.4 MB/s při náhodném zápisu vychází asi 50x nižší než byl předtím s pomocí dd, pokud tomu dobře rozumím.

Provedu test na flash Kingston DT Micro 16 GB, partition 5:

# ./fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/media/petr/8789-1BDC/test10M  --size=10M --readwrite=randwrite
test: (g=0): rw=randwrite, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=1
fio-2.0.9
Starting 1 process
test: Laying out IO file(s) (1 file(s) / 10MB)
Jobs: 1 (f=1): [w] [100.0% done] [0K/491K /s] [0 /122  iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=7573: Sat Jul 25 10:33:30 2015
  write: io=10240KB, bw=599528 B/s, iops=146 , runt= 17490msec
  cpu          : usr=0.30%, sys=2.61%, ctx=2619, majf=0, minf=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=0/d=2560, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=10240KB, aggrb=585KB/s, minb=585KB/s, maxb=585KB/s, mint=17490msec, maxt=17490msec

Disk stats (read/write):
  sdc: ios=0/2639, merge=0/0, ticks=0/133204, in_queue=122484, util=98.30%

Výsledek 585KB/s je cca 30x nižší než pomocí dd.

microDuo

Po tom, cojsme si vyzkoušeli chování HDD a jiné USB flash, otestujeme předmětný nový USB disk:

Partition 1: 8GB vfat

/dev/sdc1 on /media/petr/King8GB type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,flush,uhelper=udisks2)

Zápis

# sync; time cp /tmp/tmp10MB tmp10MB; time sync

real    0m0.093s
user    0m0.004s
sys     0m0.076s

real    0m0.651s
user    0m0.000s
sys     0m0.016s

# sync; time cp /tmp/tmp100MB tmp100MB; time sync

real    0m5.635s
user    0m0.000s
sys     0m0.832s

real    0m1.633s
user    0m0.000s
sys     0m0.020s

Vychází cca 13 MB/s.

# sync; time dd if=/dev/zero of=tmp100MB bs=1M count=10; time sync
10 485 760 bajtů (10 MB) zkopírováno, 0,138346 s, 75,8 MB/s

real    0m0.161s
user    0m0.000s
sys     0m0.116s

real    0m0.673s
user    0m0.000s
sys     0m0.012s

# sync; time dd if=/dev/zero of=tmp100MB bs=1M count=100; time sync
104 857 600 bajtů (105 MB) zkopírováno, 6,60383 s, 15,9 MB/s

real    0m6.777s
user    0m0.000s
sys     0m0.968s

real    0m0.880s
user    0m0.000s
sys     0m0.012s

Rychlost zápisu vychází cca na 12–13 MB/s.

Čtení

# /sbin/sysctl -w vm.drop_caches=3
# sync; time cp tmp100MB /dev/null; time sync

real    0m3.819s
user    0m0.000s
sys     0m0.364s

real    0m0.035s
user    0m0.004s
sys     0m0.004s

Rychlost čtení cca 26 MB/s

# /sbin/sysctl -w vm.drop_caches=3
# sync; time dd if=tmp100MB of=/dev/null bs=1M count=100; time sync
104 857 600 bajtů (105 MB) zkopírováno, 4,01736 s, 26,1 MB/s

real    0m4.036s
user    0m0.012s
sys     0m0.408s

real    0m0.042s
user    0m0.000s
sys     0m0.004s

Rychlost čtení cca 25 MB/s

Partition 2: 55GB ntfs

/dev/sdc2 on /media/petr/King55GB type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)

Zápis

# sync; time cp /tmp/tmp10MB tmp10MB; time sync

real    0m0.717s
user    0m0.000s
sys     0m0.160s

real    0m0.899s
user    0m0.004s
sys     0m0.020s

# sync; time cp /tmp/tmp100MB tmp100MB; time sync

real    0m7.221s
user    0m0.024s
sys     0m1.420s

real    0m1.697s
user    0m0.000s
sys     0m0.012s

# sync; time cp /tmp/tmp100MB tmp100MB; time sync

real    0m14.629s
user    0m0.008s
sys     0m1.464s

real    0m10.598s
user    0m0.000s
sys     0m0.032s

# sync; time cp /tmp/tmp100MB tmp100MB; time sync

real    0m12.601s
user    0m0.016s
sys     0m1.468s

real    0m9.214s
user    0m0.000s
sys     0m0.024s

Výsledky varírují; u souboru 10 MB cca 6 MB/s, u souboru 100 MB cca 4 – 11 MB/s.

# sync; time dd if=/dev/zero of=tmp100MB bs=1M count=10; time sync
10 485 760 bajtů (10 MB) zkopírováno, 0,681985 s, 15,4 MB/s

real    0m0.721s
user    0m0.000s
sys     0m0.172s

real    0m3.778s
user    0m0.000s
sys     0m0.020s

# sync; time dd if=/dev/zero of=tmp100MB bs=1M count=10; time sync
10 485 760 bajtů (10 MB) zkopírováno, 0,627772 s, 16,7 MB/s

real    0m0.636s
user    0m0.000s
sys     0m0.140s

real    0m4.191s
user    0m0.000s
sys     0m0.028s

# sync; time dd if=/dev/zero of=tmp100MB bs=1M count=100; time sync     
104 857 600 bajtů (105 MB) zkopírováno, 14,6403 s, 7,2 MB/s

real    0m14.695s
user    0m0.000s
sys     0m1.364s

real    0m8.079s
user    0m0.000s
sys     0m0.032s

# sync; time dd if=/dev/zero of=tmp100MB bs=1M count=100; time sync
104 857 600 bajtů (105 MB) zkopírováno, 13,1275 s, 8,0 MB/s

real    0m13.164s
user    0m0.016s
sys     0m1.356s

real    0m9.526s
user    0m0.000s
sys     0m0.032s

U 10 MB souboru vychází zápis cca 2 MB/s, u 100 MB souboru cca 4 MB/s, vychází tedy nižší, než když (nevím proč) měříme běžným kopírováním.

Čtení

# /sbin/sysctl -w vm.drop_caches=3
# sync; time cp tmp100MB /dev/null; time sync

real    0m0.494s
user    0m0.004s
sys     0m0.032s

real    0m0.040s
user    0m0.000s
sys     0m0.004s

# /sbin/sysctl -w vm.drop_caches=3
# sync; time cp tmp100MB /dev/null; time sync

real    0m0.510s
user    0m0.000s
sys     0m0.032s

real    0m0.046s
user    0m0.000s
sys     0m0.004s

Rychlost čtení při kopírování vychází na cca 180 MB/s.

# /sbin/sysctl -w vm.drop_caches=3
# sync; time dd if=tmp100MB of=/dev/null bs=1M count=100; time sync
10 485 760 bajtů (10 MB) zkopírováno, 0,526932 s, 19,9 MB/s

real    0m0.540s
user    0m0.000s
sys     0m0.036s

real    0m0.035s
user    0m0.004s
sys     0m0.004s

# /sbin/sysctl -w vm.drop_caches=3
# sync; time dd if=tmp100MB of=/dev/null bs=1M count=100; time sync
10 485 760 bajtů (10 MB) zkopírováno, 0,539178 s, 19,4 MB/s

real    0m0.564s
user    0m0.008s
sys     0m0.028s

real    0m0.110s
user    0m0.004s
sys     0m0.004s

Rychlost čtení vychází na cca 150 MB/s.

Závěr

U 1. partition (vfat 8 GB) vychází rychlosti cca:

zápis: 12 MB/s
čtení: 25 MB/s

U 2. partition (ntfs 53 GB) vychází rychlosti cca:

zápis: 2 – 6 MB/s
čtení: 150 MB/s

Výsledky jsou to docela pozoruhodné; zatímco u NTFS vychází rychlost zápisu asi poloviční ve srovnání se systémem VFAT, pak u čtení je asi 6x rychlejší.

Výrobce uvádí:

USB 2.0: Standard
USB 3.0:
- 70MB/s read
- 15MB/s write

Měření jsou ale prováděna na totebooku s USB 2.0, takže naměřené hodnoty nemusí dosahovat údajům výrobce pro USB 3.0.

Otázkou je, co se míní USB 2.0 Standard? w:Universal Serial Bus#USB 2.0 uvádí maximální rychlost 60MB/s v režimu Hi-Speed. pokud by se to vztahovalo pro čtení i zápis, pak ovšem údaje výrobce pro ryzhlost zápisu přes USB 3.0 nedosahují ani tohoto "standardu" 2.0. Anglická wikipedie w:en: USB#USB_2.0 dodává: Due to bus access constraints, the effective throughput of the High Speed signaling rate is limited to 35 MB/s or 280 Mbit/s.

V tomto ohledu námi naměřené hodnoty zápisu v NTFS vypadají dost nereálně, nutno znovu ověřit a přepočítat. Rychlost zápisu u NTFS je ovšem velmi snížena.

badblocks

Ještě otestujeme celý flash disk:

# badblocks -v -w -o badblocks.Kingston.microDuo64GB /dev/sdc
Hledají se špatné bloky v režimu čtení i zápis
Od bloku 0 do 61457663
Zkouším se vzorkem 0xaa: ...