Чтобы добавлять сообщения и комментарии, .

@Balancer:
Balancer

Интересно. Знаю, что фрагментация файлов в ext4 на производительности практически не сказывается. `e4defrag -c ` показывает смешные значения. Сделал дефрагментацию `/var/log/mysql`. LA среднее не изменилось. Дисковая активность по munin не изменилась. Вообще, по системным инструментам ничего не изменилось. Но из iotop исчезли mysql-процессы с 99.99% загрузки и форум стал отдавать страницы визуально раза в два быстрее :)

Думаю теперь, надо бы e4defrag для всех остальных разделов сделать для профилактики :)

@Balancer:
Balancer

ReiserFS мертва, не поддерживается и т.п. ext4 чудовищно тормозит на каталогах с тоннами мелочи. Вдобавок ко всему, на таком разделе с мелочью внезапно, едва он до половины заполнился, кончились inodes. При чём, как я понимаю, в ext4 число inodes увеличить без переформатирования нельзя? Ну и, главное, всё же, это тормоза. Надеялся я, что выделение мелких разделов под конкретные задачи, чтобы фрагментирование свободного пространства не сильно влияло, поможет — но, увы, помогло только частично.

А ReiserFS, который только и спасал в таких ситуациях, мёртв :-/

Почесал, почесал репу, да и решил рискнуть поставить на каталог с мелочью XFS. Это идёт вопреки всему моему старому опыту об этой ФС, но столько лет прошло с прежних тестов и практики — говорят, что её сильно допилили на счёт старых проблем с тормозами на мелочи. Посмотрим :)

@Hawat:
Hawat

Помню когда ext4 активно продвигали, то пели песне о шифровании файлов на уровне ФС и т.д., захотел попробовать, а инфы нет. Веде новости "В ext4 будет шифрование файлов", но без подробностей.

@Self-Perfection:
Self-Perfection

С недавних пор у меня весь rootfs на SSD. И вот смотрел я смотрел, на график записи на SSD, не вытерпел и решил как-то пооптимизировать/сократить их количество.

Итак в начале был Btrfs c relatime,compress=lzo,ssd,space_cache
MariaDB, постоянно дёргаемая Tiny Tiny RSS, давала в среднем где-то 80 KiB/sec записи на диск (а это почти 7 GiB/день!).
Пересоздал /var/lib/mysql c chattr +C (отключение copy on write). Запись от MariaDB снизилась до 70 KiB/sec

Попробовал для эксперимента перетащить /var/lib/mysql на ext4 раздел.... 30 KiB/sec!!!
Даже если примонтировать с data=journal (который, походу, пользы не приноситв этом случае, т.к. и так по-умолчанию включен innodb_doublewrite), получается всего 60 KiB/sec, что меньше, чем на Btrfs.

Смотрю на свои эксперименты и думаю, что /var надо нафиг с Btrfs выносить целиком.

@Strephil:
Strephil

Скопировал фоточку с фотика на десктоп. Для этого пришлось выяснить, что закончились иноды и поудалять ценные файлы.
Хочу теперь выложить фоточку в жуйку, но её перед этим надо обрезать, а какую переменную окружения нужно выставить, чтобы imagemagick не сегфолтился, я забыл. :-(
А в остальном всё ок, Linux вполне готов для декстопа.

@Strephil:
Strephil

У меня опять закончились иноды.

@kitt:
kitt

Ext4 это:
Максимальный размер файла 16 тебибайт
Максимальный размер тома 1 эксбибайт
Максимальная длина имени файла 255 байт

255 байт
байт
даже не символов, а байт
<

@Strephil:
Strephil

Жуйк, привет, у меня в файловой системы иноды кончились, что делать?

@Strephil:
Strephil

У меня закончились иноды :-(

@Balancer:
Balancer

Прошло почти два года — #2229209. Кеши давно устаканились, файловая система устарела... Сегодня понадобилось измерить объём каталогов. Один на «новом» (том, которому уже два года) разделе с reisrefs, другой — на старой ext4. Время подсчёта по du -h было примерно равное. При том, что под reiserfs 15Гб файлов, а под ext4 — 265Мб. Решил измерить точно, но, понятно, уже из кеша. Результат:
— reiserfs: 3.7 сек.
— ext4: 14.4 сек.

Опаньки... Решил подсчитать число файлов. time (sudo find . | wc -l)
— reiserfs: 194371 файл, 2.3 сек
— ext4: 36564 файла, 11.0 сек

@Strephil:
Strephil

15 + 1 + 15 = 31, сообщает один из разработчиков ext4 в своём твитторе:
twitter.com

@Balancer:
Balancer

В который раз натыкаюсь на потерю данных в файле. В фотке. Случаи единичные на многие десятки тысяч фото, но нет-нет, а наткнёшься на фотку, отображаемую лишь до половины, например. Размер тот же, нулей внутри не видно, таймстамп прежний. exiftool возвращает корректные данные. Но если сравнить с бэкапом — md5 файла отличается. Можно бы было винить железо, но это уже третья машина с таким поведением. Было подозрение на xfs, но сейчас случай с ext4. Натыкался на такую потерю данных при переполнении раздела с ext4 при копировании (на уже скопировавшихся файлах), но сейчас копирования нет, на разделе свободно 96Гб из 690Гб. Такие же проблемы иногда всплывают в видеоколлекции. Только там обнаружить сложнее, при просмотре столь короткий сбой в глаза не бросается, а вот при пересчёте хеша торрента, нет-нет, да попадётся раз в несколько месяцев «закачано на 99.8%». За секунды докачивается до 100%, но такое дело есть. Единственное, что объединяет все эти случаи — Gentoo. Но ситуация повторяется регулярно в течении многих лет (не меньше 10), за это время и ядер сколько сменилось, и настройки компиляции... А вот на ntfs/windows многие файлы лежать ещё с середины 1990-х гг., пережив десятки копирований, начиная с винчестеров по 133..270Мб... К сожалению, по той же Ubuntu такой статистики нет, все её инсталляции у меня «временные», основные архивы или в ntfs/windows, или ext4/xfs/gentoo.

Есть мысли, что это может быть? А сами вы с таким сталкивались? На всякий случай уточню, что речь о единичных потерях на многие сотни гигабайт за много лет, железо разное, файловые системы две разные, ядра разные...

@rwarrior:
rwarrior

~# time resize2fs /dev/vg0/backup
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/vg0/sape is mounted on /mnt/backup; on-line resizing required
old desc_blocks = 384, new_desc_blocks = 448
Performing an on-line resize of /dev/vg0/backup to 1879048192 (4k) blocks.
The filesystem on /dev/vg0/backup is now 1879048192 blocks long.


real 7m5.752s
user 0m0.188s
sys 0m4.300s

7 минут ext4 ресайзится с 6 Тб до 7. xfs делает это за несколько секунд. Одно слово — дно.

@webus:
webus

Жуик, я хочу отформатировать ntfs раздел в ext4. Сейчас он монтируется по клику мышки на иконке диска на рабочем столе. Поймет ли ubuntu (xubuntu) что ntfs том сейчас ext4 ? Раньше все это менялось в /etc/fstab. Сейчас там только тома которые подключаются автоматом при загрузке, а вот где настройки томов, которые маппятся по требованию ?

@Strephil:
Strephil

Есть гниль какая-то в nand-флешке в кубиборде. Вот fsck.ext4 никаких ошибок не показывает, а содержимое файлов испорченное. Попробовал переустановить Cubian — не помогло, ошибки появились в других файлах.

Может быть, ext4 не годится для nand?
Может быть, нужно переразбить, переразметить, какие-нибудь бэдблоки?

@partizan:
partizan

кстати, я уже месяца три живу с barrier=0 в fstab для var
полет нормальный, все быстро.

@matrixdaniil:
matrixdaniil

Сейчас буду переделывать раздел в ext4 =)
/dev/sda4 408G 181G 227G 45% /mnt/media

/dev/sda3 1 122881595 61440797+ 5 Расширенный
/dev/sda4 122882048 976770719 426944336 7 HPFS/NTFS/exFAT
/dev/sda5 * 63 122881184 61440561 83 Linux

@proton:
proton

Взял тут у @longbow сервачок погонять, влепил туда пару ssd, хотел сделать зеркало.
И тут я осознал, что совершенно не представляю, как мне с ssd жить. Кто-нибудь использует на серверах? Как разбивать, как тюнить ext4?
Особо интересует, что делать с TRIM'ом на софтварном зеркале.
P.S. Тут ещё мне советуют btrfs поднять — кто-нибудь использует в продакшене?

@partizan:
partizan

есть рисковые парни с ext4 и nobarrier в fstab? я сейчас отключил эти баръеры, и дамп который заливался три минуты сейчас загружается за 27 секунд. хотелось бы послушать истории успеха, или что у меня там похерится в случае ресета? ups то у меня есть, но от того что все ребутнется и наебнется мне кажется никто не застрахован.

@Strephil:
Strephil

Собираюсь переставлять арчик на ssd'шку.
С одной стороны, непрерывные снэпшоты это, наверное, очень удобно, и хочется попробовать NILFS2.
С другой, вот посмотрел тесты похороникса, и стало как-то не очень: phoronix.com
Наконец, она совершенно не годится для корня, потому что не умеет Extended attribute,
да и такой большой список TODO намекает, что NILFS это что-то недопиленное.

Или поставить ext4 / и nilfs для /home, или просто использовать btrfs?

@Balancer:
Balancer

В продолжение недавней темы #2225516

Первые практические оценки. Загрузка системы, процессор и io за неделю:
balancer.ru
Вертикальный раздел — перезагрузка (я сперва надеялся избавиться от kworker обновлением ядра). Потом перенос данных на новый раздел, потом заполнение кеша — следующие два дня. И, вот, сегодня день после «выхода на режим». В принципе, не так наглядно, как на соответствующем по времени графике времени генерации файлов самого munin:
balancer.ru
Хорошо видно, как было, как начал заполняться кеш, снижая нагрузку, как стало. А особенно контрастно на нагрузке за месяц:
balancer.ru

Хотя, повторюсь, не знаю, насколько именно reisrefs характерна, может быть вынос на новый раздел со свежей ext4 себя также бы повёл. По тестам, «приближённым к боевым» (многопоточность, фрагментация), ext4 у меня была заметно быстрее reisrefs. Но практика может быть иной. Не исключено, что ext4 подвержена со временем деградации, как и reiser4 (та тоже поначалу очень быстрая, а через пол-года активной работы на десктопе превратилась в ад). Вот про именно reiserfs — она, вроде, не деградирует. Старый сервер на ней проработал в жёстком режиме лет шесть и проблемы затыкания системы на дисковой активности у меня не вылезали.

Если же без картинок, то форумы перестали тормозить и при первом входе в каталог с кешем mc не вешается на десяток секунд, вход в любой момент мгновенный.

@Balancer:
Balancer

Каталог с несколькими сотнями тысяч файлов кеша в ~64k подкаталогов со степенью вложенности 3 стал тормозить совсем уже нещадно. Ежедневный find по нему даже с ionice -c3 стал основательно вешать сервер (постоянно вылезающий [kworker]). Вынес его на новый раздел и в порядке эксперимента вернулся на старую добрую reiserfs, которая с подобным много лет назад у меня справлялась неплохо. Посмотрим, что будет. Старый кеш грохнул, новый за ночь заполнился где-то на треть, наверное. Пока не тормозит, вроде.

@Strephil:
Strephil

В файловой системе Ext4 добавлена поддержка inline-хранения данных, что позволяет значительно увеличить эффективность хранения очень мелких файлов за счёт размещения данных прямо внутри inode, что значительно сэкономит дисковое пространство;

@partizan:
partizan

кстати, кто еще юзает ext4 без флага auto_da_alloc — ССЗБ, ваши данные могут после случайного ребута превратится в zero-length files. я когда-то так попал и боялся ext4, но прописал этот флаг и сейчас вроде все ок. сейчас почитал доки: kernel.org вроде этот флаг даже подефолту включен, так что, наверное вам не стоит об этом переживать. или стоит, никто не знает :)

@partizan:
partizan

ну, 41Мб/с это не так и плохо. с учетом того что такую скорость я увижу только при копировании с диска на диск, а чаще всего я копирую с интернетов, а там эти 41мб/с хватит с головой. щас еще как-то скорость чтения проверю.

@partizan:
partizan

копирую образы ведьмака 2, 16Гб, файлы по 2Гб. начало 58Мб/с, после 30% снизилась до 45Мб/с.

@Dimez:
Dimez

кстати, оказалось, что ext3 -> ext4 по ссылке ext4.wiki.kernel.org полноценно и без проблем не перейти.
Пришлось несколько опций через tune2fs дописывать, а одну или две так и не удалось дописать. Кроме того, на получившейся ext4 не работал e4defrag, ругался на отсутствие EXT4_IOC_MOVE_EXT. Пришлось уходить в однопользовательский режим и бэкапиться на внешний диск.

@side2k:
side2k

Коллеги, а чо, в ext4 мусорная корзина — это часть ФС, а не скрытая папочка?

@side2k:
side2k

Удаляю файлы — а место не высвобождается. Сделал sync. Сделал fsck. Много думал.
И вдруг вспомнил про корзину. Бля.

@Commaster:
Commaster

Как откатить второтег на 3-4 дня назад? Стопка файлов удалились, записи поверх не было. Курить лямы летающих inode-ов как-то не хочется... extundelete слеп.

@Balancer:
Balancer

Сейчас смотрю, у меня в двухнедельной давности фотосессии покоцаны четыре RAW'а. Просто повреждены с краю:
i47.tinypic.com
Без бэкапа сегодня никуда... :-/ Жаль, что на всякое астробарахло бэкапы не делаю...

@Balancer:
Balancer

Обновил дома ядро до linux-3.2.12-gentoo. И сразу то, чего много лет уже не видел. За два дня — два падения машины (материнка уже дохнет) после которых два падения FS. Правда, чинится, но странно. В /etc (!) в некоторых файлах не их содержимое(!!). Отвалились пара библиотек в /usr. Я с середины 2000-х таких глюков не видел. Хотя машина эта регулярно, пару раз в неделю падает уже с начала года. Не могу не связать внезапные глюки FS с обновлением ядра. До этого, на linux-3.2.1-gentoo-r2 всё было ок. Наверное, нужно на него вернуться.

@wilful:
wilful

*CentOS Стал случайным QA-мастером для различных вариаций блочных устройств для хостов на KVM с драйвером virtio и отключённым кэшем.
Опыт простой:
dd if=/dev/zero of=/mnt/storage/test-vm.raw bs=1G count=20

lvm,file+xfs — выдал наибольший показатель скорости записи, НО! la хоста (dom0 кому как удобнее) вырастал до бесконечности, успевал записать около 5-8Gb, дальше kill
lvm,file+ext4 — был на 20-30% медленнее, но la держался в пределах разумного, процесс шёл ровно. lvm+ext4 оказался незначительно быстрее нежели file+ext4.

Честно сказать были большие надежды на xfs. Если кто-то может подсказать, почему так херова? Я бы послушал. Сервер IBM System x3650 M2, RAID5 ServeRAID M5015, CentOS 6.2

@sss:
sss

кто то тут писал на днях что перевел с reiserfs на ext раздел для мелких файлов и всё стало быстро, так вот хотел спросить как там ситцация ?, не узудшилась за неделю ?

@sss:
sss

кто что порекомендует? и почему ?

@Reset:
Reset

На мелких файлах btrfs рулит. Нафигачил на два одинаковых раздела по 5M файлов. ext4, естественно, встала колом, а btrfs пофиг.

@datacompboy:
datacompboy

Что кроме ext4 поддерживает trim? Не хочу второй раз этот фарш наблюдать

@skobkin-ru:
skobkin-ru

Жуйк, чем восстановить файл с ext4, который случайно удалил rm -rm'ом?
P.S. Удалил на сервере файлы, есть только ssh.

@a-real-rebel:
a-real-rebel

Как можно сконвертировать ntfs в ext4? Понимаю, что можно освободить винт и форматнуть его заново, но проще конвертирование на ночь оставить.

@Balancer:
Balancer

Перехвалил я ext4. При отрубании питания тонны сбоев на /var. Конечно, случай пока единственный, но на reiserfs за несколько лет и многие десятки, если не сотни нештатных отрубаний таких потерь не было.