2016-09-07 ФС для флешек

Материал из YourcmcWiki
Перейти к: навигация, поиск
(Новая страница: «Давно уже люблю на всяких мелких/тестовых серверках / с флешек монтировать. Удобно — мес…»)
 
м
 
Строка 11: Строка 11:
 
Вот… некуда казалось бы податься любителю флешек. Но вчера возникла у меня идея — есть же btrfs! А в нём cow по дефолту для всех данных! Это ж как раз то, что нужно! И популярная, и по стабильности — не ext4, конечно, но я думаю уж точно получше экзотических nilfs’ов.
 
Вот… некуда казалось бы податься любителю флешек. Но вчера возникла у меня идея — есть же btrfs! А в нём cow по дефолту для всех данных! Это ж как раз то, что нужно! И популярная, и по стабильности — не ext4, конечно, но я думаю уж точно получше экзотических nilfs’ов.
  
И таки точно! Берём обычную флешку (5 мб/с скорость последовательной записи), бенчмаркаем случайное чтение+запись блоками по 4-16кб (с помощью fio). Получаем суммарно (чтение+запись):
+
И таки точно! Берём обычную флешку (5 мб/с скорость последовательной записи), бенчмаркаем случайное чтение+запись блоками по 4-16кб (с помощью fio, в 8 потоков). Получаем суммарно (чтение+запись):
 
* ext4=7.15 iops
 
* ext4=7.15 iops
 
* f2fs=7.38 iops
 
* f2fs=7.38 iops

Текущая версия на 12:57, 7 сентября 2016

Давно уже люблю на всяких мелких/тестовых серверках / с флешек монтировать. Удобно — места под rootfs много не надо, а скорость чтения — что случайного, что последовательного — вполне адекватная.

Другое дело, что случайная запись с обычными ФС типа ext4 очень медленная, флешки — это не SSD, гигагерцовых контроллеров и гигабайтов оперативки у них внутри нет — потому и Translation Layer внутри тупой, всё, что он обычно умеет — это «открыть» (стереть) и держать «открытыми» 2-3-4 блока стирания (обычно по 2 мб) и поддерживать в них последовательную запись. То есть, случайную запись мелкими блоками флешки не переваривают вовсе — iops на запись при этом обычно ограничивается 3-4 запросами в секунду.

Стандартно это решается лог-структурированными ФС, которые никогда не перезаписывают файлы «на месте», а всегда дописывают новую версию «в конец», одновременно постепенно освобождая место от старых блоков «в начале». То есть такие ФС чем-то похожи на кольцевой буфер :). И такие ФС под linux есть, я их ещё раньше уже тестировал: ubifs, jffs2, yaffs, logfs, nilfs2… фиг кстати знает почему, но в прошлый раз я почему-то остановился на ubifs, хотя она (как и jffs2, и yaffs) предназначена для MTD (голой флеш-памяти, не блочных устройств) и монтировать её одно извращение, и после краша она ещё не восстанавливается потом.

На самом деле из этих лучше брать nilfs2 — вроде самая живая и для блочных устройств подходит. Правда есть у неё как минимум один «нюанс» — на пустой ФС можно получить ошибку «нет свободного места», потому что она защищает (отказывается удалять) часть недавно созданных снапшотов. Время защиты вроде бы задаётся параметром `-o pp` при монтировании, но что-то я даже с pp=1 эту ошибку всё равно время от времени (при интенсивной записи) получал. Да и в общем в стабильность её работы у меня, честно говоря, особой веры нет. Экзотика, в общем.

Ещё отдельный юмор — это самсунговская F2FS (Flash-Friendly FS). Фиг знает, в каком она месте friendly и зачем она вообще создана — случайную запись она не ускоряет вообще.

Вот… некуда казалось бы податься любителю флешек. Но вчера возникла у меня идея — есть же btrfs! А в нём cow по дефолту для всех данных! Это ж как раз то, что нужно! И популярная, и по стабильности — не ext4, конечно, но я думаю уж точно получше экзотических nilfs’ов.

И таки точно! Берём обычную флешку (5 мб/с скорость последовательной записи), бенчмаркаем случайное чтение+запись блоками по 4-16кб (с помощью fio, в 8 потоков). Получаем суммарно (чтение+запись):

  • ext4=7.15 iops
  • f2fs=7.38 iops
  • nilfs2=160.8 iops (лог-структурированная ФС)
  • btrfs=128 iops (круто, почти не хуже чем nilfs2)

Короче всё, я на флешках буду btrfs теперь юзать.