USB flash disk/Kingston/DataTraveler microDuo/64 GB/rychlost/Kychot
Tato stránka je součástí projektu: | |
Příslušnost: všeobecná |
USB flash disk Kingston DataTraveler microDuo 64 GB - problémy s rychlostí
Kychot
editovat2015-07-22 koupě a problém s kopírováním souborů
editovatTuto 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
- Velikost disku se jeví jako 63 GB
- Rozdělení disku na dvě partition:
- 8 GB naformátováno jako FAT
- 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)
- Z FAT partition vytvořím bootovací disk pro Xubuntu (z obrazu .iso)
- Pomocí mc (Midnight Commander) do NTFS partiton kopíruji adresáře s fotografiemi
- 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á
- příkaz sync už nemá žádnou odezvu
- 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)
- nahraji na něj fotografie z adresáře DCIM o velikost .... . Kopírování trvá cca 6 minut
- Disk vysunu z micro USB portu
Problém se čtením flešky v jiném netbooku
editovat- Disk zasunu do USB/A portu v netbooku Mivvy m310, kde běží Xubuntu 14.04 LTS
- Přimontuje se pouze: /dev/sdc1 on /media/petr/King8GB type vfat
- 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
editovatGů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
editovatGů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 )
editovat- 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í
editovatRychlost 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
editovatfilesystem: 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
editovatJedná 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
editovat- 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
editovatyum 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
editovatPo tom, cojsme si vyzkoušeli chování HDD a jiné USB flash, otestujeme předmětný nový USB disk:
Partition 1: 8GB vfat
editovat/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
editovat# 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í
editovat# /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
editovat/dev/sdc2 on /media/petr/King55GB type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
Zápis
editovat# 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í
editovat# /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
editovatU 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
editovatJeš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: ...