Ресурс LinuxPlanet провел (http://www.linuxplanet.com/linuxplanet/tutorials/7208/1/) небольшой эксперимент с целью выяснить, какая файловая система более эффективна на Flash-накопителях и SD-картах.
Измерение скорости (указано время в секундах) записи\чтения исходников ядра на современную SD-карту (Class 10):
<font color="#461b7e">
Ext2 Ext3 Ext4 Reiser3 VFat NTFS
Запись 368 501 125 582 518 174
Чтение 53 60 53 72 98 118
</font>Пример с самой дешевой "noname" Flash-картой:
<font color="#461b7e">
Ext2 Ext3 Ext4 Reiser3 VFat NTFS
Запись 434 361 156 750 564 165
Чтение 50 64 48 87 51 125
</font>Как видно, наилучшую производительность показала файловая система Ext4.
Результаты опыта по копированию одного большого файла:
<font color="#461b7e">
Ext...URL: http://www.linuxplanet.com/linuxplanet/tutorials/7208/1/
Новость: http://www.opennet.me/opennews/art.shtml?num=28434
Обзор ниочем, почему такой скудный набор ФС?
> Обзор ниочем, почему такой скудный набор ФС?Ни а тёммм - фразочка для пригламуренных девиц, насаждаемая быдлоканалом ТНТ. Лучше ен говорить её
> Ни а тёммм - фразочка для пригламуренных девиц, насаждаемая быдлоканалом ТНТ. Лучше ен говорить еёЭто стереотип, насаждаемый всеми подряд, лучше не повторять его.
btrfs нет — тест ни о чём.
А как же UbiFS и LogFS? Они специально для флешек сделаны.
http://www.linux-mtd.infradead.org/doc/ubifs.html
> UBIFS was designed to work on top of raw flash
UbiFS сделан для работы поверх флешек без контроллера. В SD карте есть свой контроллер, который и записи размазывает, и плохие сектора обрабатывает. Так что особого смысла в UbiFS там нет.
>А как же UbiFS и LogFS? Они специально для флешек сделаны.logfs, похоже, мертво. очень жаль.
а НТФС, я так понимаю, под линухом? через FUSE?
тоды- очстранный тест
Нет конечно. Судя по результатам.
>To duplicate these tests, download the linux 2.6.34 beezyball and run "time rsync -rv from -> to && sync && umount flash". Best to live on the edge and run as root.Отторжение естественно, но против фактов не попрёшь :)
фактов?
видимо это тест на зрение. посмотрите ещё раз на последнюю таблицу:
> Ext2 Ext3 Ext4 Reiser3 VFat NTFS
> Запись 14.45 11.21 8.67 18.31 8.36 16.08
> Чтение 4.72 4.55 4.66 4.74 4.44 4.48угу, чтение в рамках погрешности. а запись? и кто тут слабое звено?
зы:
вообще-то ядро и с нтфс компилится. и на запись, и на чтение. и она намного быстрее.
а вот эта фраза - http://www.linuxplanet.com/linuxplanet/tutorials/7208/2/
>Test Methodology
>Well over 200 tests were run using eight computers running 12 operating systems.вообще ставит в тупик.
короче, фрониксы не так уж и плохи.
> короче, фрониксы не так уж и плохи.ну дык, всегда можно потратить и свое время на тесты, чтобы представить истину последней инстанции
вы цифры то посмотрели?
а истина в последней инстанции - в последнем предложении.
так что без разницы что я протестирую и как. вам это не поможет. а для себя лично я всегда делаю выводы сам.
> time rsync -rv from -> to && sync && umount flashИзмерить время записи в кэш, потом подождать синхронизации и размонтировать? Идиоты.
В статье нет информации о том как проводилось тестирование. А значит, результаты могут быть крайне неточными, синтетическими и тепличными. Известно, что много маленьких файлов записывается намного медленнее одного большого файла. Это например.
А что же очередной FAT уже без числа после названия, но с ex перед? Так уж ли много в нём различий от FAT32/FAT16/FAT12? "Победили" ли в нём главный недостаток FAT - потерю места пропорционально размеру раздела? Как там у него со скоростью и насколько уделывает его ext2 и во сколько ext4 без журналирования?
> В статье нет информации о том как проводилось тестирование.до Test Methodology не дочитали?
Да но там информации не больше чем в переводе
> "Победили" ли в нём главный недостаток FAT - потерю места пропорционально размеру раздела?будто бы ext* этого недостатка лишены, c фиксированным числом инодов то
> ... Известно, что много маленьких
> файлов записывается намного медленнее одного большого файла. Это например.Написано же: 1) записи\чтения исходников ядра - єто куча маленьких фалов; 2) Результаты опыта по копированию одного большого - єто большой файл.
> А что же очередной FAT уже без числа после названия, но с
> ex перед?Давно уж на флешках VFAT стоит, много лет. Сколько ж статей было по поводу патентных притензий с его стороны то.
> Давно уж на флешках VFAT стоит, много лет. Сколько ж статей было
> по поводу патентных притензий с его стороны то.Ну, то есть, даже если различий мало, Майкрософт позаботилась, чтобы было страшновато добавлять поддержку в ядра разных ОС. А потом договорилась с Tuxera, чтобы никому не хотелось делатьв велдосипед?
> "Победили" ли в нём главный недостаток FAT - потерю места пропорционально
> размеру раздела?У него совсем другие главные недостатки. Место при современных объемах мало кого волнует. А вот лимит на размер файла и дичайшие тормоза когда в дире несколько тысяч файлов - вот это волнует, да.
> А что же очередной FAT уже без числа после названия, но с ex перед?да не важно. Фраза в последнем тесте про большой файл вобще убила. Файл был достаточно большой?
Странно, что не тестировали UFS, раз уж взялись тестировать незаточенные под флэшки ФС.
Действительно, странно.
Надо было до кучи и ZFS потестировать... ;)
> Действительно, странно.
> Надо было до кучи и ZFS потестировать... ;)Btrfs ещё не упоминалась?
Ещё как упоминалась:"btrfs нет — тест ни о чём"
(Сообщение № 2 - от haku) :)))
Погодите, а с каких пор журналируемые файловые системы рассматриваются на накопителях с ограниченным количеством циклов перезаписи? Или статью Михалков заказал? :)
а почему все читают быстрее, чем пишут?
> а почему все читают быстрее, чем пишут?Запись всегда медленнее, нет?
имел в виду наоборот, на заметил, что указано время, а не скорость (что странно)
Вообще-то результаты в секундах указаны, а не в мегабайтах.
на флеше обычно секторы по 128к, т.е. чтобы записать скажем 64к нужно сначала прочитать целиком 128к, слить данные и затем записать 128к
> на флеше обычно секторы по 128к, т.е. чтобы записать скажем 64к нужно
> сначала прочитать целиком 128к, слить данные и затем записать 128кМинимальным элементом записи является как правило страница (как правило 1, 2 или 4Кб). А вот стирание - да, только крупными erase block-ами. Надо ли производить стирание всего блока - сильно зависит от.
>Минимальным элементом записи является как правило страница (как правило 1, 2 или 4Кб).1,2,4к это не страницы, а размеры логических блоков для ext*, с физическими секторами флеш-памяти никак не связанные
>А вот стирание - да, только крупными erase block-ами. Надо ли производить стирание всего блока - сильно зависит от.
Чушь какая-то, в NAND чтение-запись-стирание всегда производится посекторно, вне зависимости от [хз чего]
> 1,2,4к это не страницы,Читайте маны про то как флеш работает. Для начала хотя-бы что-то типа http://en.wikipedia.org/wiki/Flash_memory#Low-level_access
> а размеры логических блоков для ext*, с физическими секторами флеш-памяти никак не связанные
У NAND флеша, используемого в таких картах есть два понятия блоков: страницы и ERASE-блоки. Во первых, страницы. У реальных чипов они от 512 байтов до 4Кб (у современных чаще всего 2Кб IIRC). Это минимальный юнит который можно прочитать или записать. Если вам надо записать (в полностью стертый флеш) 20 байтов, по факту вы будете писать страницу, которая до кучи содержит и ваши 20 байтов. Запись в страницу без стирания возможна в общем случае 1 раз. Потому что операция записи как правило спускает биты из "1" в "0". А вот обратно в "1" спущенные в "0" биты выставить можно только стерев более крупный "ERASE BLOCK". При операции ERASE все биты большого erase-блока массово ставятся в "1". Erase-block (иногда его называют и сектором) как правило достаточно здоровая чушка, обычно что-то типа 64...256Кб, а его стирание - достаточно длительный процесс. В принципе, специализированные ФС которые оперируют с флешом напрямую могут избегать лишних ERASEов, метя отдельные страницы в erase-блоке как "устаревшие" путем спуска отдельных заранее оговоренных битов, что позволяет прописать одну страницу более чем однажды не проводя при этом стирание всего ERASE-блока. Эта тактика катит для NOR и SLC NAND. Для MLC все несколько хитрее - т.к. в одной ячейке хранится более 1 бита, логика произведения такого фокуса получается совершенно брейнфакерской и потому никто не заморачивается. Как правило в случае MLC специализированные ФС просто придерживаются правила что страница без стирания всего блока пищется 1 раз а определение того что она более не валидна делается иными методами. В случае SD/MMC карт, USB флех, SSD дисков и прочая - эта низкоуровневая механика сокрыта за контроллером, который обеспечивает равномерное размазывание записей, учет дефектных блоков NAND и коррекцию ошибок, эмуляцию привычных всем традиционных 512 байтных секторов из того что там есть по факту - ну в общем пытается показать что это как будто бы диск с 512-байтными секторами, не снабженный спецификой флеша. Разумеется это наглый гон :). Работать с таким "диском" именно 512-байтными секторами - очень неэффективно. Потому что запись 512 байтов потребует прочесть 2К (или сколько там) страницу, запатчить в ней 512 байтов и записать ее (а если совсем не повезло то еще и ERASE отпедалить, а это уже попадос на патчинг всей большой чушки в 64...256Кб). Ежу понятно что записать 2К одним куском в 2К страницу будет лучше чем записать то же самое как 4 раза по 512 байтов, сделав вместо 1 операции записи страницы аж 4 операции чтения-патчинга-записи. Классические утили и ФС об этом не сильно в курсе ессно, хотя в современных ФС предприняты попытки учесть это свойство флеша. Под оптимизированностью ФС для SSD что-то такое и понимают. Хотя геометрюи флеша за контроллером ФС не знает, но она может попробовать делать записи большими кусками. При этом упомянутая проблема чтения-патчинга-записи отпадает сама собой, случаи типа "скормили 4 записи по 512 байтов вместо одной на 2 кило" отстреливаеся самой ФС. Еще крайне желательно чтобы блоки ФС совпадали по своим границам с страницами и erase-блоками флеша. Иначе на запись одного блока ФС будет перетряхиваться больше страниц чем следовало бы. Скажем если страница 4Кб и блок ФС 4Кб то идеально если они совпадают. А если блок ФС попадет на пересечение страниц - запись блока портебует операций с 2-я страницами. Пролет в 2 раза - очевиден. Ну и в том же духе - если страница скажем 2Кб то хорошо если 4Кб блок лежит ровно в 2 страницах, а не в трех. Также хорошо если структуры выровнены на erase-block. Если слить фабричную ФС (FAT32) с юсб-флехи или карты - можно заметить что этот FAT скомпонован совсем не так как обычно делают тулзы ориентированные на магнитные диски. MBR вынесен в отдельный erase-блок, так что первые 128Кб или сколько там - только MBR. Это чтобы незавершенная перезапись FAT-а не привела к слету еще и MBR если питание в процессе опнется. И сами FATы и кластера удачно разложены по страницам и erase-блокам. Размеры фатов как правило кратны размеру erase-блоков, а кластера удачно распиханы по границам страниц. По этой причине фабричную ФС переформатировать стоит только если вы твердо знаете что хотите получить. Иначе есть риск обнаружить что скорость записи на носитель прилично просела по сравнению с фабричной ФС :)
> Чушь какая-то, в NAND чтение-запись-стирание всегда производится посекторно,
> вне зависимости от [хз чего]А что в вашем понимании "сектор" для начала? Page или erase-block? А то чтение-патчинг-запись производится для обоих сущностей, стирание ессно только для второй из них. У вас какие-то сильно упрощенные понятия о том что такое флеш - судя по всему вы загнали оба понятия в одну сущность :P. Или вы верите в то что те 512-байтные сектора которые показыавет вам карта - они настоящие? :) А вот и фиг вам - это контроллер карты упирается по части трансляции логики привычных дисков в логику характерную для флеша. То что вы видите и то что есть по факту - две большие разницы.
omg, я не могу. Твои посты почти как мои. Нет, это не плохо, наоборот.
ппц как люди от безделья страдают
в смысле - накладные расходы на перезапись содержимого смежных блоков высоки, вся остальная детализация по сути вопроса избыточна
Маленькое замечание - не "кластера", а "кластеры". Спасибо.
Жаль UDF нет :/
А UDF ?
Я думал опять pornonix тестировали, а нет ведь. Для флешек разработан рад специальных фс с учётом ограничений и особенностей технологии.
Только вот флешки типа SD карт снабжены своим собственным контроллером, который скрывает истинную геометрию флеша и сам делает размазывание записей и прочая. Поэтому специальные ФС как-то не слишком нужны, да и не смогут наиболее эффективно наложить свои структуры на геометрию флеша. EXT4 кстати показал себя довольно эффективным на такой карточке.
> по скорости записи - лидер Ext4.забавно. из таблицы видно, что лидер записи - VFat
Запись
Ext4 8.67
VFat 8.36
Вдоволь нахавался проблем и с VFAT и с NTFS на флешке. А скорость у NTFS что на чтение, что на запись такая топорная, что вешаться можно сразу. Авторы теста тестиров судя по выводам не проводили вообще.
авторы теста тестировАНИЕ не проводили... блин... не проснулся ещё
А также не освоили линку "исправить" под своим коментом :P. Нафига бы два комента с интервалом в минуту постить, если можно свой комент просто исправить?
Я тоже удивился, но кнопку "исправить" так и не нашёл. Вот скрин, http://imagepost.ru/images/260/2010_10_27_222458_1280x1024_s...
Где там кнопка исправить? Буду весьма благодарен.
> Я тоже удивился, но кнопку "исправить" так и не нашёл. Вот скрин,
> http://imagepost.ru/images/260/2010_10_27_222458_1280x1024_s...
> Где там кнопка исправить? Буду весьма благодарен.Хм, проверил - кнопка есть...
На моём скрине или у вас? Если на моём, то где?
> На моём скрине или у вас? Если на моём, то где?Есть страница новости, а есть тема на форуме (посвященная этой новости).
На странице новости показаны часть ответов и везде ссылки "смотреть все".
На странице темы форума есть кнопка "правка".
Сначала жмакаем на "смотреть все", потом на "правка".
> Я тоже удивился, но кнопку "исправить" так и не нашёл. Вот скрин,
> http://imagepost.ru/images/260/2010_10_27_222458_1280x1024_s...
> Где там кнопка исправить? Буду весьма благодарен.Сранность в том, что для её появления надо нажать на "смотреть всё", тогда под постом появляется линк.
*странность
Нет, первый вариант написания был точнее. Постоянно мотаться между 2-я режимами т.к. в одном не видно все коменты, а в другом не видно всю новость - это именно оно самое, в общем то ;(.
> Нет, первый вариант написания был точнее. Постоянно мотаться между 2-я режимами т.к.
> в одном не видно все коменты, а в другом не видно
> всю новость - это именно оно самое, в общем то ;(.Я думаю, это прекрасный повод продемонстрировать гибкость Открытого и Свободного ПО и заслать коммит к движку сайта :) Ну или багрепорт отправить.
> Нет, первый вариант написания был точнее. Постоянно мотаться между 2-я режимами т.к.
> в одном не видно все коменты, а в другом не видно
> всю новость - это именно оно самое, в общем то ;(.Перед обсуждением на странице с новостью жмите "Показать все", режим запомнится через cookie и в дальнейшем все комментарии под новостью будут раскрыты. По поводу кнопки "исправить" на странице с новостью, без проблем могу добавить такую ссылку по аналогии со значком "я".
Про http://wiki.opennet.ru/TODO я не забыл, все добавленные там пожелания рано или поздно будут реализованы. Например, сейчас занимаюсь переработкой формы отправки контента на сайт.
> Где там кнопка исправить? Буду весьма благодарен.Нажмите "смотреть все". Удивитесь ;). Да, у опеннета зачем-то есть два разных режима, похожих на первый взгляд но не совпадающих. Грубо говоря, "режим в котором видно всю новость" (там видно всю новость но комменты скрыты и часть фич отсутствует) и "режим в котором видно все коменты" (наоборот, часть новости может быть скрыто а все коменты показаны и больше фич для работы с ними). Нахрена оно именно вот так - я не знаю :). Ни один из этих режимов не является самодостаточным - часть фич доступна только в одном, часть - только в другом. В общем такие вот чудеса :)
>на современную SD-карту (Class 10):
>NTFS 174
>Пример с самой дешевой "noname" Flash-картой:
>NTFS 165либо дешевые флешки очень любят NTFS, либо это уже вторая опечатка в результатах (первая - противоречие чисел и текста для Ext4/vFAT).
Действительно.
Тесты бессмыслены потому что все протестированные ФС не приспособлены для работы на NAND flash. Многое зависит от логической организации чипов - размер сектора, страницы и блока в NAND массиве. Чтение например всегда производится посекторно или (если управляющий контроллер более-менее толковый) постранично. А вот стираются данные чаще целым блоком.
Теперь прикиньте - чтобы поменять всего один бит (ну ладно, пусть даже байт), нужно прочитать весь блок в оперативную память, поменять нужный байт, стереть блок в NAND и записать изменённый блок на его место.
Ну конечно ФС имеет кэш в оперативке и может накапливать изменения, но вот что она вообще знает об устройстве данного NAND чипа? Его логическая организация различается даже в одной и той же партии флэшек...
Тут уже говорили про flash wearing и про автоматическое распыление записей по всему адресному пространству флэша. Эту фишку (которая называется FTL) делают многие производители. Только вот алгоритмически это нетривиальная задача и большинство контроллеров флэшек делают это по принципу "как-нибудь", главное будет что в рекламном проспекте написать. В итоге как правило при использовании FTL сильно плавает скорость записи когда флэш записан хотя бы один-два раза под завязку.
Какие тут ещё тесты?
>Тесты бессмыслены потому что...
>...
>Какие тут ещё тесты?Вот золотые-то слова! А то развелось тестов-недорослей по принципу "покупайте нашу хренотень!"
> Вот золотые-то слова! А то развелось тестов-недорослей по принципу "покупайте нашу хренотень!"Ещё тесты заставляют смотреть, изверги
1-й косяк, то что это копирование одинаковых файлов,
которые после первого копирования будут частично жить
в оперативке.
Так шо, для объективности, очередность тестов нужно проводить 5! (120) раз!!!
т.е.
Ext2, Ext3, Ext4, Reiser3, VFat, NTFS
Ext3, Ext2, Ext4, Reiser3, VFat, NTFS
...
...
NTFS, VFat, Reiser3, Ext4, Ext2, Ext3
NTFS, VFat, Reiser3, Ext4, Ext3, Ext2Либо создать тестовую платформу, только с libc, mount, mkfs и time
и делать ребут после каждого теста.
достаточно ядра + busybox. в нем это все есть.
> достаточно ядра + busybox. в нем это все есть.Ну в общем смысл понятен - статическая предсказуемая, в пределах погрешности, система.
рейзер позорище. правильно что его в ядро не включили
ReiserFS (Reiser3.6) - первая журналируемая FS, включенная в основную ветку linux ядра
я про четверу
В чём тогда позор в контексте топика?
тролле
Как начинают напрягать обратные слэшы вместо прямых\-: