Изпечатай

[abadon]

Здравейте,

Вчера се заговорихме с един колега за хибридните дискове като този и затова колко увеличават производителността, също така че не могат да се намерят по нашите географски ширини. Това го казвам от личен опит тъй като вече 3 седмица чакам доставка на такъв от САЩ след поръчка при едни приятели български системни асемлатори, след като други две големи компании с добро име вече ми отказаха с мотива, че нито вносителя на Seagate в БГ, нито този за Европа има такива дискове в наличност. И затова се сетих за ето тази стара тема от преди 4 години когато флашките бяха значително по-скъпи след което да си я сложа в картовия четец на лаптопа, и върху нея да си инсталирам по нормален начин един линукс, като после ще си mount-на нормалния хард диск за storage само.

Затова въпроса ми е някой правил ли е подобно нещо? Има ли ефект в производителността? Струва ли си да се вложат повече пари в такива скъпи sd карти като тези на SanDisk (които дефакто направиха този стандарт) или същата работа вършат и по евтините им събратя от същия клас 10? Как стои въпроса с дълготрайността на такива карти при такава интензивна употреба от OS. Въобще който има подобен опит ще се радвам да сподели своите наблюдения.

Предварително благодаря!

Eто каква е идеята ми сега да си взема една 8GB SDHC, SanDisk Extreme® или някой по-евтин събрат като тези или тази

[vikktor]

Здравей,
Относно хибридния - http://www.multirama.bg/product/8125/tvard-disk-seagate-xt-320-gb-2-5-sata.html
Щом го има в онлайн каталога би трябвало да могат да го доставят(само предполагам).А за инсталацията в/у такава карта според мен е безмислено.Картата на сандиск дава максимум 30мб/с четене, което си е малко.За пример Seagate Momentus XT/7200.4 дават към 100-105мб/с четене и 80-90мб/с на запис.Според мен какъв и хард да имаш в лаптопа, ще е по-бърз от сандиска.Но може и да греша.

[Naka]

Как стои въпроса с дълготрайността на такива карти при такава интензивна употреба от OS.

Много зле. Флаш паметта се износва доста бързо и много често дава проблеми и развива Bad "сектори".

Обикновенно дават до около 1 милион цикъла на клетка ... ама май това производителите са си го изсмучили от пръстите.

Престави си някой сектор дето стои постоянно под 'FAT'(или inode, journal...) - таблицата. Понеже ОС-а непрекъснато пише там този сектор може да навърти 1 милион цикъла доста бързо.

Проблема е и че флаш паметите са организирани на банки - 128кб , 256 кб.. и т.н. И ако трябва да запишеш например само едни бит се търка целият блок. Т.е. заради един бит се износват едновреммено 256 Kbyte-а.

Заради тези проблеми всички флаш устройства изполват алгоритми за разпледеляне на изосването. http://en.wikipedia.org/wiki/Wear_leveling

Е предполагам че при разните по-специални флаш устройства като SSD специално е обърнато внимание на тези проблеми и те са много по-надежни да съхраняват информация.

Eто каква е идеята ми сега да си взема една 8GB SDHC, SanDisk Extreme® или някой по-евтин събрат като тези или тази

И аз искам да питам. Това гола плаш памет ли е? Т.е. има ли контролер който да прави  Wear_leveling?

И като какво се монтира такава памет. USB-? Кой ще го прави този Wear_leveling.

Мисля че даже имаше в кернела и някаква специална Флаш-файлова система направена точно за това?

[v_badev]

В linux има няколко такива файлови системи (jffs2, ubifs и logfs), но както е написал vikktor, SD картите са доста по-бавни от твърдите дискове. SanDisk Extreme® са клас 10, което е около 80Mb трансфер. Това е доста под възможностите дори и на нормален твърд диск работещ на 5400 оборота.

Според мен в упражнението има смисъл само ако сглобяваш компютър в който не трябва да има движещи се части (примерно за автомобил).

[abadon]

@Victor - аз искам модела който е с 500G нормална част и 4G SSD.

[b@]Naka[/b] - Това е добър въпрос за тази 8GB SDHC, SanDisk Extreme® не знам каква е. Ще го проверя и ще пиша, че и на мен ми се стори странно скъпа двойно над събратята и.

@v_badev - И моята идея беше такава да ползвам jffs2. Ще ги чекна и другите две файлови системи които не са ми известни на този етап.

Иначе относно четенето/писането да и аз го мислех, че дори на нормален диск му дават по-големи стойности, но пък от друга страна флашовете имат по-бързо време за търсене или поне така показват мойте basic тестове които направих на лаптопа си със microSD картата от телефона си, която е от клас 4 значително по-бавна от клас 10 моделите. Ето какво показват те сравнено със диска на лаптопа ми:

SD картата е форматирана със fat32 (просто не ми се занимава да я преформатирам) срещу дял от диска на лаптопа ми форматирана със esx4.

SD card:
./seeker /dev/sdb1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sdb1 [3772MB], wait 30 seconds..............................
Results: 584 seeks/second, 1.71 ms random access time

Hard disk:
./seeker /dev/sda3
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda3 [100000MB], wait 30 seconds..............................
Results: 64 seeks/second, 15.59 ms random access time

не ми се занимава да ти пиша повече обяснения затова ти пействам output-а от конзолата ще разбереш сам:

root@abadon:/home/genko# gcc -o seekmark -lpthread seekmark-0.3.c
root@abadon:/home/genko# chmod +x seekmark
root@abadon:/home/genko# ./seekmark -t 1 -s 1000 -f /dev/sdb1

Benchmarking against /dev/sdb1 3772 MB

Spawning worker 0 to do 1000 seeks
thread 0 completed, time: 1.80, 554.32 seeks/sec, 1.8ms per request

total time: 1.80, time per request(ms): 1.804
554.32 total seeks per sec, 554.32 seeks per sec per thread

root@abadon:/home/genko# ./seekmark -t 2 -s 1000 -f /dev/sdb1

Benchmarking against /dev/sdb1 3772 MB

Spawning worker 0 to do 1000 seeks
Spawning worker 1 to do 1000 seeks
thread 1 completed, time: 7.36, 135.94 seeks/sec, 7.4ms per request
thread 0 completed, time: 7.41, 134.93 seeks/sec, 7.4ms per request

total time: 7.41, time per request(ms): 3.706
269.83 total seeks per sec, 134.92 seeks per sec per thread

root@abadon:/home/genko# ./seekmark -t 1 -s 1000 -f /dev/sda3

Benchmarking against /dev/sda3 100000 MB

Spawning worker 0 to do 1000 seeks
thread 0 completed, time: 14.79, 67.63 seeks/sec, 14.8ms per request

total time: 14.79, time per request(ms): 14.787
67.63 total seeks per sec, 67.63 seeks per sec per thread

root@abadon:/home/genko# ./seekmark -t 2 -s 1000 -f /dev/sda3

Benchmarking against /dev/sda3 100000 MB

Spawning worker 0 to do 1000 seeks
Spawning worker 1 to do 1000 seeks
thread 1 completed, time: 27.90, 35.84 seeks/sec, 27.9ms per request
thread 0 completed, time: 28.00, 35.72 seeks/sec, 28.0ms per request

total time: 28.00, time per request(ms): 13.998
71.44 total seeks per sec, 35.72 seeks per sec per thread

root@abadon:/home/genko#

Пращам и програмчетата

[v_badev]

Явно си заслужава да се направи един по-обстоен бенчмарк с реално инсталирана система на sd карта (може би с Phoronix Test Suite). Ще е интересно дали доста по-малкото време за търсене на SD картите компенсира по-бавният трансфер.

[abadon]

Ето и някой допълнителни тестове които направих с fio:

SD Micro Card Class 4:

fio random-read-test.fio
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 128MB)
Jobs: 1 (f=1): [r] [100.0% done] [2695K/0K /s] [658/0 iops] [eta 00m:00s]
random-read: (groupid=0, jobs=1): err= 0: pid=2646
  read : io=131072KB, bw=2923KB/s, iops=730, runt= 44846msec
    clat (usec): min=843, max=7326, avg=1361.11, stdev=219.63
    bw (KB/s) : min= 2560, max= 3024, per=100.11%, avg=2925.29, stdev=98.86
  cpu          : usr=0.20%, sys=2.34%, ctx=32853, majf=0, minf=23
  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 r/w: total=32768/0, short=0/0
     lat (usec): 1000=1.79%
     lat (msec): 2=96.75%, 4=1.35%, 10=0.12%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=2922KB/s, minb=2992KB/s, maxb=2992KB/s, mint=44846msec, maxt=44846msec

Disk stats (read/write):
  sdb: ios=32716/1, merge=0/0, ticks=44550/150, in_queue=44550, util=99.43%
r

HDD

# fio random-read-test.fio
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=sync, iodepth=1
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 128MB)
Jobs: 1 (f=1)
random-read: (groupid=0, jobs=1): err= 0: pid=2878
  read : io=131072KB, bw=83913KB/s, iops=20978, runt=  1562msec
    clat (usec): min=35, max=9031, avg=41.37, stdev=93.10
    bw (KB/s) : min=82352, max=86064, per=99.87%, avg=83802.67, stdev=1984.34
  cpu          : usr=17.94%, sys=19.22%, ctx=32771, majf=0, minf=23
  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 r/w: total=32768/0, short=0/0
     lat (usec): 50=98.53%, 100=1.05%, 250=0.23%, 500=0.05%, 750=0.02%
     lat (usec): 1000=0.03%
     lat (msec): 2=0.02%, 4=0.05%, 10=0.01%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=83912KB/s, minb=85926KB/s, maxb=85926KB/s, mint=1562msec, maxt=1562msec

Disk stats (read/write):
  sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

SD Micro Card Class 4:

fio random-read-test-aio.fio
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=8
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 128MB)
Jobs: 1 (f=1): [r] [100.0% done] [2174K/0K /s] [531/0 iops] [eta 00m:00s]
random-read: (groupid=0, jobs=1): err= 0: pid=2889
  read : io=131072KB, bw=2152KB/s, iops=537, runt= 60914msec
    slat (usec): min=8, max=247, avg=16.04, stdev= 5.38
    clat (msec): min=2, max=71, avg=14.85, stdev= 7.77
    bw (KB/s) : min= 1988, max= 2291, per=100.05%, avg=2152.15, stdev=37.03
  cpu          : usr=0.56%, sys=1.15%, ctx=32723, majf=0, minf=29
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=100.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.1%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued r/w: total=32768/0, short=0/0

     lat (msec): 4=0.06%, 10=33.55%, 20=41.13%, 50=25.18%, 100=0.07%

Run status group 0 (all jobs):
   READ: io=131072KB, aggrb=2151KB/s, minb=2203KB/s, maxb=2203KB/s, mint=60914msec, maxt=60914msec

Disk stats (read/write):
  sdb: ios=32655/0, merge=33/0, ticks=483730/0, in_queue=498150, util=100.00%

HDD Тука нещо ми fail-на но не можах да разбера защо

fio random-read-test-aio.fio
random-read: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=8
Starting 1 process
random-read: Laying out IO file(s) (1 file(s) / 128MB)
fio: pid=2901, err=22/file:filesetup.c:452, func=open(/windows/D/random-read.1.0), error=Invalid argument


Run status group 0 (all jobs):

Disk stats (read/write):
  sda: ios=0/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%

Ще разгледам и за технологиите които е писано по-нагоре, като примерно Wear leveling-а. Това си мисля ако wear leveling-а не може да се подкара дали няма да се забърза работата, ако се премести журнала на файловата система на флашката на tmpfs в RAM-а примерно и си направи човек едно скриптче което когато си гаси компютъра да му синква нещата от tmpfs на флашката. Също така интересен ми е въпроса какво би станало ако журнала на файловата система се загуби, тъй като не съм изпадал в такава ситуация.

[radolin]

Относно wear leveling-a няма какво да се притесняваш. Всички USB флашки или SD карти имат вграден контролер, който се грижи за това. Тези JFFS, UBIFS и т.н. се ползват само когато работиш директно с гол флаш чип, или т.нар MTD (Memory technology devices).

За файлова система ext3/ext4 е ОК. Вече ако искаш може да мислиш някакви варианти за намаляне на писанията изобщо, като монтиранe с noatime и изключване на журнала.

Слагането на журнала в РАМ диск е обезмисля неговата функция, така че ако толкова гониш бързодействие по-добре просто го изключи.

За тестовете ти със seek time - ами при флаш паметта реално няма такъв. Това е времето през което хард диска позиционира главата на точното място и изчаква плочата да се завърти за да прочете даден сектор.

[Naka]

Това си мисля ако wear leveling-а не може да се подкара дали няма да се забърза работата, ако се премести журнала на файловата система на флашката на tmpfs в RAM-а примерно и си направи човек едно скриптче което когато си гаси компютъра да му синква нещата от tmpfs на флашката.

Това да се премести журнала на друго устройство е изключително важно. И аз съм се замислял много сериозно за това. Обикновенно каквото съм чел по форумите препоръчват флаш памет да се монтира само като EXT2 или FAT защото няма журнал.

noatime е също изключелно важно.

Всички USB флашки или SD карти имат вграден контролер, който се грижи за това

За USB-флашките да всичките имат. Но не съм сигурен как стои въпроса с SD карти-те и кой го прави. Има ли изобщо?

Изобщо не мисля че много по-добрият seek time ще ускори работите. Много по важен е суровият постояннен трансфер.
Sustained transfer при хардовете.

Имаше много голяма разлика в производителнотта когато хардовете бяха около 30 Mbyte/sec .. след това станаха 60-80 Mbyte/sec а сега са 120  Mbyte/sec.
Много е забележимо.

[abadon]

Относно wear leveling-a няма какво да се притесняваш. Всички USB флашки или SD карти имат вграден контролер, който се грижи за това.

Сега се порових из нета и установявам, че май само най-новите SD карти от клас UHS-I го имат. За този клас разбрах едва сега като почнах да търся повече информация и ревюта на SDHC, SanDisk Extreme® От това което прочетох от предния линк и от още няколко места едно от които официална сайта на SanDisk разбирам, че тази карта има само ESP Technology (Enhanced Super-Parallel Processing Technology) правеща това:

Yoram Cedar, SanDisk's senior vice-president of engineering, said, "SanDisk has developed a new ESP (Enhanced Super-Parallel Processing) technology that gives our new SanDisk Extreme III line its performance advantages. ESP technology is a major technology breakthrough that combines our in-house design of both NAND flash memory chips and controller chips using advanced 32-bit RISC processing and leading edge algorithms. Our engineers worked closely with major camera manufacturers in developing our new ESP technology."

 Cedar also explained, "ESP has super-parallel write and read operations that are coupled with an accelerated flash data bus architecture to allow data to be transferred at twice the rate of most competitive cards. In addition, the ESP architecture streamlines every aspect of read and write data transfer operations through advanced hardware automation. The ESP architecture effectively removes the card as the bottleneck in data storage applications."

А вече при по-новия събрат SanDisk Extreme® Pro™ SDHC™ UHS-I се споменава за това:

Extreme reliability and endurance, the SanDisk Extreme® Pro™ SDHC™ UHS-I Power Core™ Controller’s firmware increases endurance through wear leveling. The Power Core controller’s advanced Error Correction Code (ECC) engine improves overall data integrity and reliability of the card during read and write.

Друго нещо което не мога да разбера ясно са тези скорости х ето примерно тази Kingston SDHC UHS-I UltimateXX пищат

Performance: 233x – up to 60MB/sec. read, and 35MB/sec. write

а при по-стария модел SanDisk Extreme® SDHC™ оферират

Extreme speed at up to 30MB/second read/write (200X)*

Тук съм объркан вече колко е 1х не е ли равно на 150Kb?

Иначе от това което намерих в нета за целта на бързодействието май най-добре е да се ползва тази карта Delkin Elite 633X UHS-I SDHC която ми изглежда най-нов модел и която според производителя има скорост от "633X, което ще рече до 95MB/s скорост на четене и до 80MB/s скорост на запис." и която има Error Correction Code (ECC) и Wear Leveling,

Изобщо не мисля че много по-добрият seek time ще ускори работите. Много по важен е суровият постояннен трансфер. Sustained transfer при хардовете.

А този трансфер няма ли да падне заради по-високия seek time ако имаш фрагментация и/или няколко паралелни запитвания за четене/писане?

Друго нещо което се сетих е как би се отразило ползването на SD карта на батерията на лаптопа? Примерно аз когато съм на работа почти не ползвам нищо от запаметената информация на хард диска а си ползвам основно инсталирания софтуер като ssh, remote desktop и браузър. В такива моменти SD картата няма ли да ползва по-малко енергия от стандартен хард? Също така ако няма заявки към харда той дали няма да си паркира главите и да ползва по-малко енергия?

[Naka]

Сетих се още нещо.

Флаш паметите работят много лошо заради I/O_scheduler-a който е по дефаулт в кърнела (заради стандартните хард дискове). Просто при тях няма глави и няма какво да се оптимизира.

Най добре работеха при Deadline scheduler или без scheduler.
Имаше някъде един пост тук, дето бях писал всичко относно scheduler-а и флаш паметите.


Относно това ESP (Enhanced Super-Parallel Processing) technology мисля си че много от рекламираните като бързи флаш устройства правят нещо подобно. Т.е. не е кой знае каква революционна технология.

Вместо да има само един чип флаш памет има няколко и контролера чете едновременно и от всичките. Тогава скоростта на трансфер няма да е колкото е ограничението на 1 чип а ще е X броя на чиповете. Нещо подобно е на ускортението което се получва при RAID масивите.

[abadon]

Прочетох ти поста тук което ме накара да се позамисля за Линукс I/O scheduler-ите и намерих тази статия която много добре обяснява работата на Linus Elevator (който беше в Linux 2.4 kernels), Deadline и Anticipatory. Не можах да намеря хубава статия синтезираща на куп всичко около Noop scheduler-a и cfq scheduler-a 

Ето какво показват тестовете на всички scheduler-и със въпросната ми SD card-та class 4 от фото апарата ми. Първия тест пише 256МВ файл на нея. Втория тест прочита предния новосъздаден файл. Третия тест прочита всички 456 снимки намиращи се на тази карта. Ето какво показват:

Noop scheduler:

root@abadon:/mnt# echo noop > /sys/block/sdb/queue/scheduler
root@abadon:/mnt# cat /sys/block/sdb/queue/scheduler
[noop] anticipatory deadline cfq
root@abadon:/mnt# dd if=/dev/zero of=file bs=1M count=256
256+0 прочетени блока
256+0 записани блока
изкопирани са 268435456 байта (268 MB), 21,73 s, 12,4 MB/s
root@abadon:/mnt# time cat file > /dev/null

real    0m0.329s
user    0m0.010s
sys     0m0.140s

root@abadon:/mnt/DCIM/100OLYMP# time find . -type f -exec cat '{}' ';' > /dev/null

real    3m10.704s
user    0m1.870s
sys     0m3.250s

Anticipatory scheduler:

root@abadon:/mnt# echo anticipatory > /sys/block/sdb/queue/scheduler
root@abadon:/mnt# cat /sys/block/sdb/queue/scheduler
noop [anticipatory] deadline cfq
root@abadon:/mnt# dd if=/dev/zero of=file bs=1M count=256
256+0 прочетени блока
256+0 записани блока
изкопирани са 268435456 байта (268 MB), 10,6424 s, 25,2 MB/s
root@abadon:/mnt# time cat file > /dev/null

real    0m0.344s
user    0m0.000s
sys     0m0.150s

root@abadon:/mnt/DCIM/100OLYMP# time find . -type f -exec cat '{}' ';' > /dev/null

real    3m10.938s
user    0m2.310s
sys     0m2.820s

Deadline scheduler:

root@abadon:/mnt# echo deadline > /sys/block/sdb/queue/scheduler
root@abadon:/mnt# cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq
root@abadon:/mnt# dd if=/dev/zero of=file bs=1M count=256
256+0 прочетени блока
256+0 записани блока
изкопирани са 268435456 байта (268 MB), 12,6343 s, 21,2 MB/s
root@abadon:/mnt# time cat file > /dev/null

real    0m0.296s
user    0m0.010s
sys     0m0.140s

root@abadon:/mnt/DCIM/100OLYMP# time find . -type f -exec cat '{}' ';' > /dev/null

real    3m10.994s
user    0m2.720s
sys     0m2.420s

Cfq scheduler:

root@abadon:/mnt# dd if=/dev/zero of=file bs=1M count=256
256+0 прочетени блока
256+0 записани блока
изкопирани са 268435456 байта (268 MB), 14,1088 s, 19,0 MB/s
root@abadon:/mnt# time cat file > /dev/null

real    0m0.395s
user    0m0.000s
sys     0m0.150s

root@abadon:/mnt/DCIM/100OLYMP# time find . -type f -exec cat '{}' ';' > /dev/null

real    3m10.510s
user    0m3.170s
sys     0m2.010s

Въпреки че в нета пишат, че със SSD дискове е най-добре да се ползва Noop scheduler аз мисля, че най-добре е за SD карти и flash-ки да се ползва Anticipatory scheduler-а, който се справя най-бързо с писането, както се вижда от направените резултати.