LINUX.ORG.RU
ФорумTalks

[SSD][Btrfs][Ext4][ЖЖ]Выбор файловой системы для SSD


0

2

Купил Crucial RealSSD C300 в замен умирающему HDD под корень системы. Озаботившись выбором файловой системы решил устроить небольшое тестирование.
На SSD создал 2 раздела по 15Гб, 1й раздел с Ext4, 2й раздел с Btrfs. Опции монтирования:

/dev/sdc1 /mnt/Ext4   ext4    defaults,noatime,nodiratime,discard 0 1
/dev/sdc2 /mnt/btrfs  btrfs   noatime,nodiratime,ssd,compress=lzo,nobarrier 0 1

Ext4
1Gb @ 1M
[root@ArchLinux Ext4]# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
скопировано 1073741824 байта (1,1 GB), 8,1236 c, 132 MB/c
[root@ArchLinux Ext4]# dd if=tempfile of=/dev/null bs=1M count=1024
скопировано 1073741824 байта (1,1 GB), 3,97064 c, 270 MB/c

1Gb @ 1k
[root@ArchLinux Ext4]# dd if=/dev/zero of=testfile bs=4k count=262144
скопировано 1073741824 байта (1,1 GB), 6,86382 c, 156 MB/c
[root@ArchLinux Ext4]# dd if=testfile of=/dev/null bs=4k count=262144
скопировано 1073741824 байта (1,1 GB), 4,1518 c, 259 MB/c

4Gb @ 1M
[root@ArchLinux Ext4]# dd if=/dev/zero of=tempfile bs=1M count=4096 conv=fdatasync,notrunc
скопировано 4294967296 байт (4,3 GB), 34,0361 c, 126 MB/c
[root@ArchLinux Ext4]# dd if=tempfile of=/dev/null bs=1M count=4096
скопировано 4294967296 байт (4,3 GB), 15,9441 c, 269 MB/c



Btrfs
1Gb @ 1M
[root@ArchLinux btrfs]# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc
скопировано 1073741824 байта (1,1 GB), 1,58031 c, 679 MB/c
[root@ArchLinux btrfs]# dd if=tempfile of=/dev/null bs=1M count=1024
скопировано 1073741824 байта (1,1 GB), 3,69538 c, 291 MB/c

1Gb @ 64K
[root@ArchLinux btrfs]# dd if=/dev/zero of=testfile bs=64k count=16384
скопировано 1073741824 байта (1,1 GB), 2,05684 c, 522 MB/c
[root@ArchLinux btrfs]# dd if=testfile of=/dev/null bs=64k count=16384
скопировано 1073741824 байта (1,1 GB), 8,661 c, 124 MB/c

1Gb @ 1k
[root@ArchLinux btrfs]# dd if=/dev/zero of=testfile bs=4k count=262144
скопировано 1073741824 байта (1,1 GB), 4,47562 c, 240 MB/c
[root@ArchLinux btrfs]# dd if=testfile of=/dev/null bs=4k count=262144
скопировано 1073741824 байта (1,1 GB), 10,4336 c, 103 MB/c

4Gb @ 1M
[root@ArchLinux btrfs]# dd if=/dev/zero of=tempfile bs=1M count=4096 conv=fdatasync,notrunc
скопировано 4294967296 байт (4,3 GB), 7,17725 c, 598 MB/c
[root@ArchLinux btrfs]# dd if=tempfile of=/dev/null bs=1M count=4096
скопировано 4294967296 байт (4,3 GB), 22,0999 c, 194 MB/c

Сравнение не в пользу Btrfs + еще статус беты у этой системы. Кто может подкинуть способов тестирования чтобы окончательно утвердится в выборе фс?

★★★★★

bonnie++, dbench, например.

P.S. Я не заморачивался и поставил дефолтную ФС, только со stride/stripe-width = 32 или 128

Adjkru ★★★★★ ()

1. dd oflags=datasync

2. почему ext4 с барьерами а btrfs нет?

3. одно с дискардами, другое без. оно же на скорость записи влияет.

4. btrfs со сжатем, ext4 без

имхо, сравнение кислого с длинным.

mmarkk ()

Если бы я такой винт купил, то первым делом сделал бы многотхреадный срач / удаление с запуском fsck время от времени и подсчётом md5 от файлов.

Зачем? на предмет правильности работы discard. Если в этом сравнительно новом алгоритме будет ошибка, то представляешь что это значит? Думаю у этих фс алгоритмы зашедуливания дискардов разные.

mmarkk ()
Ответ на: комментарий от Lordwind

Нормальные SSD (в том числе указанный) сами подобной чушью занимаются, им эти велосипеды ни к чему.

pekmop1024 ★★★★★ ()
Ответ на: комментарий от pekmop1024

Бред. SSD сам не может знать какие данные мне нужны а какие нет. SSD лишь занимается перемапливанием. и именно в этом тормоза и заключаются во время записи, против которых и есть команда discаrd (она же trim)

mmarkk ()
Ответ на: комментарий от mmarkk

> Бред.

ты хотя бы матчасть про новые контроллеры глянул, что-ли, прежде чем так фейспалмить. Была даже паника со стороны спецслужб о том, что новые SSD не позволяют восстанавливать убитую инфу.

pekmop1024 ★★★★★ ()
Ответ на: комментарий от pekmop1024

Как раз из-за TRIM'а и не позволяют. TRIM помечает что теперь в данном месте может находиться что угодно, и ФС больше не нужна эта область диска. Что позволяет накопителю более свободно «перетасовывать» данные.

Adjkru ★★★★★ ()

Как-то не понятно, почему в btrfs на запись получается быстрее чем на чтение %)

vitruss ★★★★ ()
Ответ на: комментарий от mmarkk

1 можно поподробней, что дает?

2 не знал что на btrfs можно ставить nobarrier

3 в примерах в инете не замечал дикард для btrfs думал невзлетит.

4 ссылку на то как в ext4 сделать прозрачное сжатие.

имхо, сравнение кислого с длинным.

Я выложил свои измерения здесь для того чтобы мне указали где я возможно не прав.

Behem0th ★★★★★ ()
Ответ на: комментарий от mmarkk

Слишком долго и трудно для меня, а я ленив=(

с запуском fsck время от времени

С этим на btrfs проблемы. Это еще одна причина почему не хочется ставить btrfs.

Behem0th ★★★★★ ()
Ответ на: комментарий от Adjkru

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

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

Adjkru ★★★★★ ()
Ответ на: комментарий от pekmop1024

RTFM! для работы TRIM нужна поддержка в контроллере диска, в ядре ОС и в ФС, сейчас трим есть только в ext4 и btrfs (из линуховых ФС)

так шо я не собираюсь обижать ваши нежные чувства к рейзеру и прочему хорошо зарекомендовавшему себя старью, но для SSD они не подходят

Lordwind ★★★★★ ()
Ответ на: комментарий от different_thing

> Делать нечего же людям

Есть что делать - btrfs. Как допилят, буду с радостью юзать.

zloy_buratino ()
Ответ на: комментарий от Elemir

В то время я не особо интересовался btrfs и рейзером так что это имя сразу в голову не пришло.

SSD будет использоваться под корень /var будет вынесен на HDD так что теоретически проблем не должно возникнуть. Лелею надежду что с тех пор были приняты меры по устранению этого недостатка.

Behem0th ★★★★★ ()
Ответ на: комментарий от bsdfun

Я подумал что вы про 4й. А про 3й я чтото не подумал. Есть ли у 3го специальные опции для SSd дисков?

Behem0th ★★★★★ ()
Ответ на: комментарий от Behem0th

> Я подумал что вы про 4й. А про 3й я чтото не подумал. Есть ли у 3го специальные опции для SSd дисков?

Можеть быть можно отключить журнал, но у меня HDD, так что опциями для SSD я не интересовался.
А вот мегабакс в своем бложике пишет что лучше всего для ZFS:
http://optimization.hardlinux.ru/?page_id=224

bsdfun ★★★★★ ()
Ответ на: комментарий от Jetty

Не подводит тех, кто готов раз в год покупать новые ssd, так как старые сточены?

Elemir ()
Ответ на: комментарий от Elemir

Выгнали некомпетентных, набрали компетентных? =)

Да и честно говоря без fsck страшно использовать btrfs, еслиб эта файловая система показала большое превосходство над ext4 можно было и рискнуть.

Behem0th ★★★★★ ()
Ответ на: комментарий от Behem0th

> /var будет вынесен на HDD

мне кажется можно вынести оттуда не все директории, /var/lib оставить бы, пакман значительно ускорится :)

Adjkru ★★★★★ ()
Ответ на: комментарий от Behem0th

Количество найденных там багов уже перевалило за сотню и многие из них приводят к потери данных. Особенно опасна для ext4 пропажа питания - так даже корень можно похерить и немодифицируемые данные

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от bsdfun

Автор той темы, насколько я помню, — большой любитель RC-ядер. Вот ссылка на багзиллу ядра была бы более к месту, потому что здешние онолитеки доверия не заслуживают.

GotF ★★★★★ ()
Ответ на: комментарий от DNA_Seq

>> Особенно опасна была для ext4 в 2008 году пропажа питания

Так точнее, толстячок.

GotF ★★★★★ ()
Ответ на: комментарий от DNA_Seq

У меня сейчас корень и хомяк на ext4, питание пропадает не скажу чтоб часто но случаи бывают. Потери данных после этого не наблюдал.

Behem0th ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.