LINUX.ORG.RU

Релиз E2fsprogs 1.42.8

 , , ,


1

1

E2fsprogs — это набор утилит для работы с Ext2, Ext3 и Ext4.

Список изменений в 1.42.8:

  • Исправление ошибки в e2fsprogs v1.42 при «e2image -s»;
  • В mke2fs добавлена проверка неверного размера журнала;
  • Убрана опция "-R", вместо неё добавлена "-E";
  • В mke2fs теперь устанавливаются реальные uid/gid, для этого добавлен новый параметр root_owner;
  • Tune2fs теперь не может задать размера inode больше, чем размер блока;
  • Исправление изменения размера некоторых ФС flex_bg && !resize_inode в режиме off-line, e2image теперь нормально работает с ФС большого размера;
  • В E2fsck появилась возможность восстанавливать extent trees и убрана проверка значения расширенных атрибутов нулевой длины;
  • В resize2fs добавлена проверка выхода блоков битовых карт за допустимые границы уменьшенной файловой системы;
  • Исправление в Debugfs с extent_inode для аргументов split_node, replace_node и insert_node;
  • Исправление парсинга 's' в parse_num_blocks2.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Убрана опция"-R", вместо неё добавлена "-E".

Странно, у меня в 1.41.14 это уже.

vsemnazlo ()

Пацаны,я не понял.на какой строке можно говорить «решето»?

anonymous ()

Похоже что дефрагментатора мы никогда не увидим, даже самого простенького.

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

а зачем ?

дефрагментировать :). Если бы ещё свободное место зануляло то можно было уменьшить образ виртуалок в qcow2. Впрочем, я щас тупо в raw всё храню, как-то с ними меньше проблем.

true_admin ★★★★★ ()

Помнится, в релизе ядра 3.8 появилась вот эта фича: «в файловой системе Ext4 реализована поддержка хранения мелких файлов непосредственно в inode». Новые e2fsprogs как-то могут включить эту возможность на старых разделах с ext4 или это вообще по иному включается?

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

могут включить эту возможность на старых разделах с ext4

Могут, но никаких гарантий, сам понимаешь, что фс в линуксе мягко говоря не самые надежные.

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

фс в линуксе мягко говоря не самые надежные

Толсто.

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

А мне тут другое говорили. Даже на ssd разница видна, раза в полтора-два. Я думаю в поиске найдётся.

Хотя, я не заморачиваюсь на ssd, да.

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

relatime,discard,data=writeback,barrier=0,nobh

Но что это даёт я не проверял :). По-моему, relatime на моих данных влияет незначительно, остальное не знаю.

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

Была статья в одном из номеров LXF — про SSD, что мол если SSD поддерживает команду TRIM, то опция монтирования discard, указанная для ext4, сообщает накопителю через этот TRIM о неиспользуемых блоках, что делает износ ячеек более равномерным; а noatime уменьшает интенсивность записи аттрибутов при доступе к файлу только на чтение. Как-то так.

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

Я это всё понимаю :). Я не знаю как это на производительность влияет (сколько процентов прироста и в каких ситуациях можно ожидать, хотя немного пофантазировать могу).

Ещё интересно работает ли trim на usb3 накопителях. Потому что скорость флешек это беда.

true_admin ★★★★★ ()
Последнее исправление: true_admin (всего исправлений: 1)
Ответ на: комментарий от true_admin

barrier=0

Кстати, к вопросу о стабильности в случае сбоев. IO-планировщик noop и barrier=0 это безопасно, или барьеры в любом случае нужны? NCQ исключаем из рассмотрения, считая что даже если он есть диск успеет записать все что ему отправили.

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

Я не спец в этом, но сохранность и непротиворечивость данных никто не гарантирует. Журнал в первую очередь защищает структуру ФС. Толку от журнала если свет отключат посередине длинной записи? Максимум на что можно надеяться что после прохождения барьера всё действительно записалось на диск. Но многие ли приложения используют всякие man fsync и умеют проверять консистентность своих данных?

Для тех случаев когда действительно нужна ~100% консистентность данных нужно принимать особые шаги, типа double buffering как сделано в mysql inodb.

NCQ исключаем из рассмотрения

так для этого барьеры и придумали чтобы никакой NCQ не повлиял на это, не? https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Barriers_on_by_default

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

Пацаны,я не понял.на какой строке можно говорить «решето»?

На строке anonymous (24.06.2013 11:28:48)

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

Могут, но никаких гарантий, сам понимаешь, что фс в линуксе мягко говоря не самые надежные.

ext4 уж точно надёжнее ntfs

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

Я не спец в этом, но сохранность и непротиворечивость данных никто не гарантирует.

Согласен, даже journal=data может не спасти. Это в любом случае придется делать на уровне приложения, или очень грамотно расставлять fsync и очередность записи данных.

так для этого барьеры и придумали чтобы никакой NCQ не повлиял на это, не?

В принципе, да. Но у harddrive, например, относительно небольшой кеш и есть время среагировать на отрубание питания. Так что вполне возможно, что пропадание питания не будет приводить к пропаданию данных лежащих в кеше и еще незаписанных на диск. Если это так, то NCQ или не NCQ особой роли не сыграют (ну может быть за исключением возможности попасть на BadBlock). Если винт при пропадании питания ничего дописывать даже не собирается, а сразу паркует головки, то тогда NCQ будет мешать и нужны барьеры. Хотел это выяснить...

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

Ещё интересно работает ли trim на usb3 накопителях.

Ещё интересно, можно ли это выяснить, ведь hdparm не дружит с USB...

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

можно ли это выяснить

По скорости можно :). но единственная моя флешка щас, пардон, служит диском для сервера.

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

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

Думаю что сразу паркует, это самое разумное. Рассказы про «использование инерции блинов для дозаписи данных» это сказки. Буфер у винта может быть и 64метра, причём при высокой фрагментации там запись может быть в кучу мест.

true_admin ★★★★★ ()

Ждём, пока эту новую версию впилят в SystemRescueCd :-)

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