Impuls Dec 27 2011 at 11:51

Попытка ускорить запись на flash-ки

5 min

16K

Algorithms*

-7

Comments 16

Kolicher Dec 27 2011 at 12:00

круто, чё

SabMakc Dec 27 2011 at 12:38

Помнится, когда баловался со скоростями внешних сортировок, пришлось грузить MS DOS с флешки, чтобы скорости протестировать.
Иначе кеширование все замеры убивало напрочь.
Работал я в Windows, не думаю, что Linux о кешировании ни чего не знает.

Кстати, по этой же причине предложенный алгоритм не внушает доверия — мало того, что во флешках / винтах запись идет блоками, так еще и физический доступ к устройству нельзя получить, все работает через множество буферов.

Impuls Dec 27 2011 at 12:52

Linux о кешировании, конечно, знает. Поэтому я писал с помощью системных вызовов read/write. Ниже этого уровня я больше ничего не знаю. По этой же причине бралось среднее время записи. Дальше шло тестирование не абстрактных единицах времени: сравнение — 1; запись — 45.07; чтение — 12.33. Как по мне, то в качестве приближенного метода — вполне сгодится. Да и общую картину видно: скорость записи во много раз превышает скорости чтения и сравнения. Хотя было бы интересно узнать точные результаты измерений.

webkumo Dec 27 2011 at 14:53

драйвер уровня ядра же. Добавляется возможность писать в обход буфера ;)

Ilya_Smelykh Dec 27 2011 at 17:05

И read() и write() не избавляет вас от кеширования страниц.

Ilya_Smelykh Dec 27 2011 at 17:11

Страниц виртуальной памяти в Linux, конечно. Так, например, чтение файла второй раз должно быть быстрее, потому что он частично остался в кэше.

imsamurai Dec 27 2011 at 12:48

А у меня вот есть флешка PQI traveling disk i221 на 16 Гб, так под виндой она жутко тормознутая, тогда как в линуксе в несколько раз быстрее. И чтение и запись. Интересно, с чем это связано?

Impuls Dec 27 2011 at 12:56

Я бы так не радовался. Помните как в винде была реализована запись на дискеты? Запись уже прошла, а дискетка еще жужжит. В линуксе осталось тоже самое, когда в винде это как-то пофиксили (или сделали вид что пофиксили).

polym0rph Dec 27 2011 at 14:00

Отложенная запись это называется. Применительно к флэшкам в винде, если не ошибаюсь, не используется начиная с висты.

lorc Dec 27 2011 at 13:20

Теория хорошая, но к сожалению флешки работают по другому. Флешка разбита на страницы (например — 4кб). Единственный способ записи одного бита — это перевести 1 в 0. Единственный бит невозможно</b/ перевести из 0 в 1. Можно только стереть полностью страницу. Стирание страницы как раз и приводит к установке всех её бит в 1. И как раз самая длительная операция — это стирание. Я не помню точных цифр, но она занимает на порядки больше времени, чем запись ( перевод 1 в 0).
Кстати, знаете почему флешки так называются? :) Для стирания на ячейки надо подать импульс высокого напряжения — около 12В (насколько я помню). Этот импульс (вспышка) и стирает ячейки. С другой стороны USB обеспеычивает питание только 5В. До 12В напряжение подымается специальными «насосами заряда» (charge pump). Которым тоже нужно время для зарядки.

lorc Dec 27 2011 at 13:21

Черт. Неправильно написал закрывающий тег болда. Звыняйте.

polym0rph Dec 27 2011 at 14:01

Главное, по сути верно.

Impuls Dec 27 2011 at 15:04

Да уж. Жалко, но уж очень хотелось бы. Очень хороший комментарий.

steel_ne Dec 27 2011 at 16:08

Интересно, а если наперед, в фоновом режиме постирать свободные страницы? Ускорится запись?

lorc Dec 27 2011 at 16:31

А как вы будете их стирать? Их стирает контроллер когда посчитает нужным (точнее, когда точно знает, что страница уже не используется). Можно конечно попытаться записать во все сектора 0xFF. Но контроллер всё равно будет считать, что страница используется.
Конечно, если контроллер умный, и увидит что страница чистая, то возможно он второй раз стирать её не будет. Но я, честно говоря не знаю, бывают ли такие контроллеры.

Кстати, на самом деле размер страницы всегда больше, чем чем степень двойки (на 32,64,128 байт, зависит от размера страницы). Остальная часть используется для out-of-band data (служебных меток, информации для востановления данных, и т.д.). Вполне возможно, что если записать в сектор 0xFF, то контроллер запихнет в область OOB какие-то свои данные (типа счетчика стирания и ECC). И ему потом всё равно придется стирать всю страницу целиком, что бы обновить информацию.

Хотя, SSD контроллеры поддерживают функцию TRIM. Она как раз сообщает что сектор (страница) не используется и её можно стереть. Понимают ли USB флешки такую штуку — я не знаю.

compdemon Dec 28 2011 at 14:03

Еще не забываем, что у флеш-памяти все-таки есть ограниченный по количеству циклов записи ресурс. Каждый раз очищая в фоновом режиме «неиспользуемые» страницы мы будет тратить этот ресурс впустую.

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

Кстати именно поэтому кучу мелких файлов на флешку писать намного дольше, чем один большой — запись каждого файлика ведет к изменению и перезаписи и страницы памяти с данными файла и области, где расположена ФС. Тогда как при большом файле данные идут большим сплошным потоком и контроллер может разбить данные на фрагменты соответствующие блокам записи и один раз обновить запись о файле в области ФС.