Закончились иноды в /var

Сделаешь в нём ls и всё, идёшь пить чай.

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

Нет чтения, нет затупов. Вот такая беда

случаются в подавляющем случае исключительно при чтении всего списка файлов

Ага, только что вот тест сделал: ls в _пустом_ каталоге на ext4 занял 37 секунд. И выдал ничего, как и ожидалось. Никаких сортировок, ни одного stat'а, просто собрать все куски директории с диска. Фрагментация.

Хм... странно. В пустом ?

В смысле в том самом где только что было 500K файлов, потом удаленных ?

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

В пустом ?

Да, в пустом. Перед запуском ls я сбрасывал кэши (vm.drop_caches=3). Дело в том, что в семействе ext каталоги растут, когда в них много файлов, но никогда не уменьшаются. А так как растут они редко, оптимизаций аллокатора не используется, и на несвежей ФС фрагментация очень сильная. У меня получилось 403 фрагмента на 11МБ директории. Это ещё терпимо, может быть гораздо хуже.

readdir запускает чтение всех этих кусочков и не заканчивает, пока не прочитает все, даже если файлов в директории нет. Отсюда и тормоза.

блин, не пойму... почему в этой теме ни кто ни чтроски не написал про btrfs %) %)

Я-то проверял. Делал тесты в декабре. 1-2 миллиона файлов. Создание, удаление по очереди, в случайном порядке и т.п.

ты проверял какой-то странный юзкейс. Я могу понять, как можно получить МНОГО файлов в одном каталоге, вот ТС например получил. Это ошибка, но иногда действительно надо. Сейчас вот сделал каталог на 1М файлов (несколько секунд делала), проверил время доступа - ниже погрешности

$ time md5sum xaabvvmn
e472585cfed7ad3b887380227bd8c7f2  xaabvvmn

real	0m0.007s
user	0m0.001s
sys	0m0.004s

$ time touch zzz

real	0m0.011s
user	0m0.001s
sys	0m0.005s

$ time rm -fv xaabyvik
удалён «xaabyvik»

real	0m0.010s
user	0m0.001s
sys	0m0.005s

$ time find -name "xaa*" -delete
^C

real	57m11.353s
user	0m0.332s
sys	0m5.724s

$ time find |wc -l
600553

real	0m0.293s
user	0m0.122s
sys	0m0.170s
$ time ls |wc -l
600552

real	0m2.620s
user	0m0.733s
sys	0m1.786s

(заметь - команда ls выполняется на порядок медленнее find)

Сейчас удалю остальные 600K файлов, и проверим твой миф про «каталоги-убийцы», а ты мне пока напомни, как ты число фрагментов считаешь

размер каталога сейчас

$ ls -lhd .
drwxr-xr-x 2 drb users 21M марта 22 09:42 ./

ни кто ни чтроски не написал про btrfs %) %)

Все в школе (ну, кроме тебя).

find /var/ -type d -exec find ...

find /var -printf '%h\n' | uniq -c | sort -n

Все в школе (ну, кроме тебя).

ну тогда ды и фиг бы с вами. проверю сам :)... (что вобщем-то щаз и делаю)

думаю результаты вам не интересны, поэтому когда они будут готовы показывать смысла нет...

ты проверял какой-то странный юзкейс

Это для тебя он странный. Обычное стресс-тестирование по принципу белого ящика.

проверил время доступа - ниже погрешности

Ну ты просто генератор перлов. Я же писал, readdir + 50 тысяч stat'ов выполняются три секунды. Подели три на пятьдесят тысяч и сравни с погрешностью вывода time.

Время вставки нового файла тоже минимально

delalloc

проверим твой миф

Кеши не забудь сбросить, или перезагрузиться.

как ты число фрагментов считаешь

/usr/sbin/filefrag <filename>

Кеши не забудь сбросить, или перезагрузиться.

а сбросить кэш перед надо удалением файлов? или перед проверкой получившегося «каталога-убийцы»?

а сбросить кэш перед надо удалением файлов? или перед проверкой получившегося «каталога-убийцы»?

После удаления; до проверки.

блин, не пойму... почему в этой теме ни кто ни чтроски не написал про btrfs %) %)

Пользователям btrfs писать некогда, они спасают данные.

Это для тебя он странный. Обычное стресс-тестирование по принципу белого ящика.

ты не понял, в чём странность: знаешь почему автомобили разгоняют до 100км/ч и бьют апстену, а с десктопами так не делают? Потому-что для автомобиля - это _возможный_ юзкейс, а вот для десктопа - невозможный. Для смартфона возможный, но вряд-ли владельца этого смартфона заинтересует результат такого теста(в отличие от автомобиля).

Вот твоё тестирование - тоже такое надуманное.

Ну ты просто генератор перлов. Я же писал, readdir + 50 тысяч stat'ов выполняются три секунды. Подели три на пятьдесят тысяч и сравни с погрешностью вывода time.

в этом моём тесте readdir НЕ выполнялось, и каталог НЕ загружался в память целиком. Ты можешь понять, что доступ к _одному_ файлу, и readdir — разные задачи?

delalloc

угу. Если вставлять 1М файлов, то что, тоже?

Кеши не забудь сбросить, или перезагрузиться.

не забуду, не переживай.

/usr/sbin/filefrag <filename>

266 extents found

Для 1М файлов - немного.

Пользователям btrfs писать некогда, они спасают данные.

«спасли» давно, используя FORMAT C:, теперь пишут с венды про «говнолинукс».

Пользователям btrfs писать некогда, они спасают данные.

хм... такое ощущение что речь идёт о какой-то сенсационной новости, про btrfs, которую я почему-то пропустил мимо глаз... %) %)

Вот твоё тестирование - тоже такое надуманное.

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

Ты можешь понять, что доступ к _одному_ файлу, и readdir — разные задачи?

Числа поделил? При делении на 50000 время одиного вызова размывается. Получится 1/50000 времени вызова getdents и время вызова lstat.

Если вставлять 1М файлов, то что, тоже?

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

Для 1М файлов - немного.

Но для 20-метрового файла многовато, не находишь?

Сейчас ещё выяснится, что ты на SSD тестируешь.

«спасли» давно, используя FORMAT C:, теперь пишут с венды про «говнолинукс».

Конечно, куда там устаревшей NTFS тягаться с современными и надёжными ФС в линуксе.

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

я знаю. Но это не наш случай. Даже если придерживаться твоей аналогии, то почему её не бьют молотком, считая удары, пока оно работает? А потому-что «экстремальные условия» бывают разные. И разрушения за 10 лет можно в первом приближении моделировать повышенной температурой. А вот ударные нагрузки более тяжёлым молотком смоделировать не получается. Один удар тяжёлым молотком не эквивалентен 10и ударам молотка в 10 раз меньше весом.

Числа поделил?

нет, и не буду. Ибо это разные вещи.

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

что я увижу? я и без твоих графиков знаю, как увеличивается скорость вставки.

Но для 20-метрового файла многовато, не находишь?

учти, этот 20и метровый файл рос одновременно с созданием 1М других файлов, причём места было только на эти файлы (они создавались пока место св. не кончилось). Чудес не бывает.

Сейчас ещё выяснится, что ты на SSD тестируешь.

да. Я разве не сказал? А почему - нет? На HDD у меня было тоже самое. Только дольше.

речь идёт о какой-то сенсационной новости

Новость не сенсационная, она всем давно известна. Просто некоторые доверяют разработчику, который говорит что оно не готово, а другие решают проверить это на своём опыте.

Конечно, куда там устаревшей NTFS тягаться с современными и надёжными ФС в линуксе.

btrfs ещё не доделали. Цыплят по осени считают.

btrfs ещё не доделали

Я о чём и говорю. Просто некоторых тянет использовать свежие глючные недоделки вместо стабильных и годами проверенных решений.

btrfs ещё не доделали. Цыплят по осени считают.

но поэкспериментировать же можно уже сегодня? ничего ведь страшного не случится?

(я имею ввиду наш эксперимент с большим числом файлов, и проблему с заканчивающимися inode :))

> а сбросить кэш перед надо удалением файлов? или перед проверкой получившегося «каталога-убийцы»?

После удаления; до проверки.

кстате говоря — после команды ``sudo sysctl vm.drop_caches=3`` на моём компьютере (правда НЕ на том на котором btrfs) — начинают какое-то время тормозить самые банальные операции. причём на несколько секунд...

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

какой use case мы эмулируем в случае очищенного кэша? я даже домашний компьютер выключаю через режим sleep . перезагрузку не очень люблю (делаю при обновлении ядра)...

не судите строго — просто всякие мысли вслух :)

Время вставки нового файла тоже минимально
как и время удаления _одного_ файла

Осталось открыть общественности что именно у тебя ЛЮТО ТУПИЛО в

другая ФС начала-бы просто люто тупить с большим числом файлов в одной «папке». Я проверял.

И какой такой кривой use-case ты проверял

Сейчас ещё выяснится, что ты на SSD тестируешь.

Дык Linux на десктопе

какой use case мы эмулируем в случае очищенного кэша?

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

но поэкспериментировать же можно уже сегодня? ничего ведь страшного не случится?

самое страшное - запорешь раздел с этой btrfs. попробуй, диск не расколется.

PS: Хотя это наверное не самое страшное. Страшнее, если ты выводы сделаешь слишком рано. В интернетах например Over9000 всяких гадостей про EXT4, которые люди выяснили, когда она была в тестовом виде. Теперь это - мифы, но живучие.

кстате говоря — после команды ``sudo sysctl vm.drop_caches=3`` на моём компьютере (правда НЕ на том на котором btrfs) — начинают какое-то время тормозить самые банальные операции. причём на несколько секунд...

вот ссылка: http://www.opennet.ru/tips/sml/43.shtml

кеш нужен для ускорения работы, ваш Кэп.

какой use case мы эмулируем в случае очищенного кэша?

случай _первого_ обращения. А не десятого.

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

да вроде в настройках по-умолчанию ничего не рапортует, ищи где ты это рапортование включил.

И какой такой кривой use-case ты проверял

создание/доступ/удаление одного-нескольких файлов в папке, где УЖЕ находится МНОГО файлов. Ну например как здесь - спул почтового сервера за два года.

Дык Linux на десктопе

ага. С него пишу.

да вроде в настройках по-умолчанию ничего не рапортует, ищи где ты это рапортование включил.

читай тему - у него warning из-за кривого конфига php.ini.

создание/доступ/удаление одного-нескольких файлов в папке, где УЖЕ находится МНОГО файлов.

Хватит путаться в показаниях

Время вставки нового файла тоже минимально
как и время удаления _одного_ файла

И страдать склерозом Закончились иноды в /var (комментарий)

случай _первого_ обращения. А не десятого.

ну вот и я про тоже самое :)

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

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

Ну например как здесь - спул почтового сервера за два года.

Здесь у человека 42384 файла за два года, и вставшая раком FS

У меня же 107818 файлов за два месяца и прекрасно функционирующая FS.

Внимание вопрос - ЧЯДНТ ? И какую хрень ты там якобы проверял ?

Один удар тяжёлым молотком не эквивалентен 10и ударам молотка в 10 раз меньше весом.

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

что я увижу?

График. Но зачем строить графики, если ты и без них всё знаешь? :-D Да ты просто уникум, который знает результаты экспериментов до их проведения. Зачем вообще экспериментировать? Надо спросить у drBatty. Нет, серьёзно, какой смысл избегать построения графика? Сложно подправить скрипт, чтобы он измерял время? Ты скажи, я сюда опубликую, там десяток строк.

учти, этот 20и метровый файл рос одновременно с созданием 1М других файлов, причём места было только на эти файлы (они создавались пока место св. не кончилось). Чудес не бывает.

О, уже ищешь оправдания для своей любимой ФС. Я вот пустые файлы создавал, по нуль байт. Есть куча непрерывных блоков на разделе, проверяю созданием файла. Почему у меня под миллион пустых файлов директория стала разбита на 679 фрагментов?

да. Я разве не сказал? А почему - нет? На HDD у меня было тоже самое.

Это глупо. Эффекты масштабирования не всегда линейные. Я уже рассказал, почему именно случаются тормоза. Очевидно, что для SSD они тоже случатся, время увеличится в несколько раз, но этой разницы не заметить. Разницу между секундой и тридцатью видно на глаз, а разницу между миллисекундой и тридцатью не заметить без инструментов.

Решил сыграть на SSD vs HDD? Так себе ход, ты только себя выставляешь в дурном свете.

создание/доступ/удаление одного-нескольких файлов в папке, где УЖЕ находится МНОГО файлов.

Хватит путаться в показаниях

я не путаюсь. Может ты меня с кем-то путаешь?

Время вставки нового файла тоже минимально как и время удаления _одного_ файла

И страдать склерозом Закончились иноды в /var (комментарий)

у меня всё хорошо с памятью. По ссылке я говорил о «папках», а «папки» бывают только в венде. А в цитате я говорил о EXT4. Мне жаль тебя, если ты не осилил умение читать.

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

просто IRL обращение будет первым, а десятым оно будет только в синтетическом тесте. Зачем тебе IRL десять раз подряд читать одно и то же?

я имею ввиду наш эксперимент с большим числом файлов,

Много файлов создадутся легко, но число метаданных быстро подскочит (CoW кусков дерева, старые не сразу чистятся). За счёт этого фрагментация будет расти медленнее, чем в reiser4, где старые ветки быстро помечаются свободными и переиспользуются. Разделение на зоны метаданных и зоны данных в btrfs облегчают последствия фрагментации, так как метаданные локализованы в одном месте. И дефрагментировать проще.

и проблему с заканчивающимися inode

На brtfs не закончатся, так как их там нет в той форме, что на ext4. Btrfs из себя представляет кучу B+-деревьев (или C-tree или S-tree, всякий по своему зовёт), записи о файлах, директориях добавляются в виде элементов листьев этих деревьев. Так же как в reiserfs, только в btrfs всё отложенное.

Тест остановится по причине нехватки места, даже если создавать файлы нулевого объёма.

Здесь у человека 42384 файла за два года, и вставшая раком FS

лень искать, но я уже говорил о том, что выделять такое малое количество инодов в данном случае - неправильно. Т.ч. — ССЗБ.

У меня же 107818 файлов за два месяца и прекрасно функционирующая FS. Внимание вопрос - ЧЯДНТ

сравниваешь неправильно. Если-бы ТС ставил-бы всё на диск C:, то такой проблемы-бы не возникло, инодов-бы хватило. Но он зачем-то выделил маленький var (в принципе правильно, но вот инодов тоже выделилось мало, mkfs не знала, что хоть раздел маленький, но файлов там может быть много).

И какую хрень ты там якобы проверял ?

100K файлов на сегодня - мало. Даже говнонтфс вытягивает на сегодняшнем железе. Лет через 5 и FAT вытянет. А я проверял лет 10 назад, тогда это было МНОГО.

По ссылке я говорил о «папках», а «папки» бывают только в венде.

Неа, открой гном и удивись. LOL

Nautilus File Manager

6.6. Managing Your Files and Folders 6.6.g. Creating a Folder

To create a folder, perform the following steps:

Select the folder where you want to create the new folder.

Choose File->Create Folder. Alternatively, right-click on the background of the window, then choose Create Folder.

KDE проверять лень, но более чем уверен что папки и там используются.

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

А в цитате я говорил о EXT4.

А в цитате про люто тормозить ты витиевато врал. А сейчас выкручиваешься Вот и всё.

100K файлов на сегодня - мало.

Для склеротивок специально напоминаю - у топик стартера файлов менее 50К - а FS уже стоит раком

сравниваешь неправильно.

Это ты, бедалага, неправильно читаешь - у топикстартера раздел, у меня раздел, у него на нем каталог с 50К файлами и у меня на нем каталог с 100К файлами, у топикстартера FS на разделе стоит раком, у меня FS с того же раздела спокойно раздает файлы на скорости 50-60Мб/с

лень искать, но я уже говорил о том, что выделять такое малое количество инодов в данном случае - неправильно. Т.ч. — ССЗБ.

Что бы бросаться такими словами как ССЗБ - ты должен привести факты что топикстартер указал количество inode вручную.

В противном случае это проблема мантейнеров, дистрибутива и наконец, как правильно указано в тега, ext4 - которой до сих пор ажно в 21-м веке нужно указывать конкретное количество inode

просто IRL обращение будет первым, а десятым оно будет только в синтетическом тесте. Зачем тебе IRL десять раз подряд читать одно и то же?

тыг я же и говорю что IRL у всех разный :)

за рабочей станцией — я например намного чаще обращаюсь к тем директориям — к которым я постоянно собственно и обращаюсь.

а если речь идёт о сервере — тыг там вообще постоянно идёт обращение к одним и тем же директориям :)

Лет через 5 и FAT вытянет.

в vfat вроде бы ограничение на количество файлов — в пределах одной директории? не больше 65K как помню :)

иле это уже убрано ограничение?

Теперь это - мифы, но живучие.

Мифы мифы https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?id=...

спасиб за разъеснение!

на df -i кстате там да — нули

аналогична интенсификации операций с файлами.

неправильные это примеры. Сравнивать нужно те условия, которые будут IRL. В случае наработки на отказ у нас тупо нет времени ждать 10 лет. Но это иной случай. Сделать 1М файлов мы можем, это не долго.

График. Но зачем строить графики, если ты и без них всё знаешь?

конечно знаю. Если ты не знаешь, почитай Кнута, там есть и формула, и её вывод. И узнаешь, как зависит время от числа файлов в данном случае. Зачем мне строить график? Кнуту я верю всё равно больше.

Зачем вообще экспериментировать? Надо спросить у drBatty.

можешь сам посмотреть что там в EXT4, а потом почитать Кнута, дабы узнать зависимость времени от количества. Я тут не при чём. Я просто посмотрел и почитал. Да, я ещё и проверил, дабы убедится, что я всё правильно понял. Теория согласуется с практикой.

О, уже ищешь оправдания для своей любимой ФС. Я вот пустые файлы создавал, по нуль байт. Есть куча непрерывных блоков на разделе, проверяю созданием файла. Почему у меня под миллион пустых файлов директория стала разбита на 679 фрагментов?

размер файлов не имеет значения. Они в любом случае занимают 4К. Да, EXT4 - это УГ, потому-что плохо хранит миллион пустых файлов. Согласен. Какую практическую ценность имеет данный результат, и для кого?

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

Это глупо. Эффекты масштабирования не всегда линейные. Я уже рассказал, почему именно случаются тормоза. Очевидно, что для SSD они тоже случатся, время увеличится в несколько раз, но этой разницы не заметить. Разницу между секундой и тридцатью видно на глаз, а разницу между миллисекундой и тридцатью не заметить без инструментов.

суть в том, что если доступ занимает мало времени, то его можно считать равным нулю. Причина в том, что в этом случае, время работы остальной части программы намного больше, и разницу между 1 и 10 миллисекундами ты не узнаешь даже RDTSC.

Решил сыграть на SSD vs HDD? Так себе ход, ты только себя выставляешь в дурном свете.

не. В очередной раз «проверил» тот очевидный факт, что фундаментальные математические выкладки и выводы НЕ зависят от железа, и от тех, кто их(выкладки) делает. На SSD получаются точно такие же(качественно) результаты, как и на HDD.

Потому как моё мнение и понимание ничуть не изменились. Хоть на SSD, хоть на квантовом компьютере будет тоже самое.

А выводы следующие:

• скорость доступа к одному файлу в каталоге падает пропорционально логарифму количества файлов в этом каталоге. Т.е. довольно слабо. В каталоге, который в 1М раз больше скорость будет в log₂1048576=20 раз меньше, если дерево бинарное (оно не бинарное, но это ничего не меняет. Пруф у Кнута). Мы наблюдаем время, которое ниже границы погрешности измерения.
• скорость доступа ко всем фалам конечно пропорциональна логарифму умноженному на количество файлов, т.е. каталог в 1М раз больший потребует для перебора всех файлов в 20М раз больше времени. Что мы и наблюдаем в примере с find.
• скорость ls ещё меньше, ибо требуется сортировка, а время сортировки пропорционально O(N*log(N)*M), где M средняя длинна имени. Т.к. N у нас немалое, сортировка получается в 10 раз дольше доступа, см. пример с ls. Впрочем - это уже от железа сильно зависит. На бюджетном HDD и хорошем CPU будет примерно одинаково ИМХО.