Debian переходит к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру

Если речь про то время, то всё проще: для раскладывания файлов по дисками не надо было дорабатывать вообще ничего, и ни одной проблемы им это не добавило - значит решение хорошее.

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

А вот «изобретение» рейда это затраты как на собственно путь к идее, так и на написание и отладку кода её реализации. Однозначно отказать.

Там даже не RAID, в современном понимании, изобретать надо было. Нужно было реализовать драйвер виртуального диска, который мапит свои сектора на сектора физических дисков, делая второй физический диск продолжением первого и далее по цепочке. Это довольно просто реализовать и это был бы задел на будущее.

Там даже не RAID, в современном понимании, изобретать надо было.

Да плевать как ты это назовёшь. Подмонтировать ещё диск это одна команда из 3-4 слов, всё уже готово. Любое дополнительное действие, не дающее при этом пользы больше чем эта команда - лишнее и не должно вообще рассматриваться.

К сожалению это не так. Из той же статьи:

If a process is allowed to dirty a large amount of memory, the kernel will find itself committed to writing a chunk of data that might take minutes to transfer to persistent storage. All that data clogs up the I/O queues, possibly delaying other operations. And, as soon as somebody calls sync(), things stop until that entire queue is written.

Короче если какой-то процесс умудряется создавать грязные страницы быстрее, чем они успевают записываться на диск (любой), то очередь I/O забивается и тормозит (вплоть до зависания) всю систему. Так как пул страниц и очередь общие на всех.

Если у меня какая то левая писанина творит настолько не то

Что значит «настолько не то»? Это обычная утечка памяти. Причём не самая быстрая, эти 40 гигов часа два жрались.

Или чтобы когда твой емакс выжрет 40гб и попросит ещё, оом-киллер не похерил твоих данных

Ю АР ДУИНГ ИТ ВРОНГ!!!

Сходи почитай ещё раз как OOM работает и кого он убивает. Кстати, сейчас есть отлично настраиваемый systemd-oomd. А ещё есть очень годный nohang.

Например чтобы выполнить опрацию на 12гб оперативки на машине с 8. Или выполнить 4 задачи по 1 гб оперативки на машине с 2 гб паралельно.

Ну, то есть, если у тебя всё норм с железом, то он не нужен. А если не норм, то операции со свопом будут тормозить так, что проще арендовать инстанс на AWS на 5 минут. Я понял.

Так как пул страниц и очередь общие на всех

Уже давно есть blk-mq и соотв. планировщики ввода-вывода вроде умолчального ныне mq-deadline.

Кстати да, статья старая и похоже написана до появления multiqueue в ядре.

На современных многоядерных системах ситуация должна быть значительно лучше.

Там даже не RAID, в современном понимании, изобретать надо было.

Да плевать как ты это назовёшь. Подмонтировать ещё диск это одна команда из 3-4 слов, всё уже готово.

Мы ходим по кругу. Я уже сказал, что это костыль. Теперь ты говоришь мне: «смотри как всё просто, одна команда из 3-4 слов, всё уже готово». Ну да, костыли именно так и готовят. Куяк куяк и в продакшен.

Любое дополнительное действие, не дающее при этом пользы больше чем эта команда - лишнее и не должно вообще рассматриваться.

Польза виртуального диска, составляемого из нескольких физических дисков, очень даже очевидна. Тем болле в ОС с файловой системой V6FS, которая поддерживает размер тома до двух терабайт. И это во времена, когда жёсткие диски были лишь на единицы мегабайт.

На современных многоядерных системах ситуация должна быть значительно лучше.

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

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

Не, настолько правильного балансирования вручную не достичь! Единственное что реально работает - разбрасывание одного файла мелкими блоками на разные диски, желательно так, чтобы 2 соседних блока всегда лежали на разных дисках. Иначе каждая отдельная файловая операция будет обрабатываться на скорости 1 диска, а ускорения можно достичь только при многопоточной работе, и то оно окажется нестабильным, иногда в большой минус.

Не, настолько правильного балансирования вручную не достичь!

Норм достичь.

Единственное что реально работает - разбрасывание одного файла мелкими блоками на разные диски, желательно так, чтобы 2 соседних блока всегда лежали на разных дисках.

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

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

Всмысле «только»? Это само собой разумеется. Нафиг тебе сдался нагруженный однопоток? Все нагруженные системы многопоточные и есть, и сильно многопоточные. Вот у нас в работе 100 запросов на чтение (от 100 разных файлов), 15 уйдут на первый диск, 10 на второй, 12 на третий итд. Это в разы лучше чем каждый диск проедет по всем 100 нужным местам.

А писать sync в терминал после каждого сохранения файла это юзерфрендли?

sync и так делается по таймеру каждые 120с, так что не каждый раз а только после завершения крупной и важной работы. Можно кстати на панель кнопочку повесить. Рядом с монитором дисковой активности и апплетом извлечения дисков. Ну это если ты по каким то причинам не доверяешь уведомлению «можно извлекать» файлменеджера.

B «аварийное отмонтирование» может произойти не по вине пользователя, а допустим от потери питания.

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

Все хорошо, только проблема с получасовым ожиданием sync/unmount в случае копирования большого объема данных

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

Я беру ноут, ставлю на него новый ссд, ставлю туда винду для игрушек, начинаю придумывать бэкапы и для этого создаю лайв-флешку. Флешка старая, 8Гб 2010-х годов, на ней просто тупо Девуан в консольном режиме с nm, самбой и десятком утилит. Бэкапы - тупое сжатие диска через zbackup на шару.

Всё это требует написания скриптов и проверки совместимости zbackup'ов, самосборного arm7l одной из первых версий и х86_64 актуального из репы. И вот задача: я беру одно из своих хранилищь (В-дерево из кучи мелких и средних файликов, гига 2-3) чтобы перепаковать пару тестовых файлов из старого в новое и потом обратно и затем извлечь и сравнить контрольные суммы. Копирую с шары, скорость эзернета 10-12 М/сек, скорость физической записи 2,2 М/сек. За счёт кеширования я заканиваю серию тестов ещё до того, как исходное дерево физически скопируется на лайв-флешку.

С тем же успехом это могла быть папка на 1000 фото и видео, которую я гонял бы через редактор или сортировал бы в Дигикаме. И мне было бы глубоко паралельно, это древний юсб2.0 или современный юсб3.2 с флешем, приближенным к ссд.

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

Гонял, не замедляет. На двух дисках порядка 1,2-1,5 ускорения.

Это само собой разумеется.

В смысле разумеется? Мозаичку придумали чтобы 2 диска гоняли один файл на скорости 1,8-2,0х

Гонял, не замедляет. На двух дисках порядка 1,2-1,5 ускорения.

По сравнению с чем? С одним диском - да. Но два независимых диска дадут х2 ускорение, то есть твоя штука будет в 1.3-1.7 раз медленнее их.

В смысле разумеется? Мозаичку придумали чтобы 2 диска гоняли один файл на скорости 1,8-2,0х

Круто, мозаика ускоряет чтение в почти ненужном сценарии использования когда ты зачем-то читаешь последовательно один единственный файл и тебе вдруг не хватает для этого скорости одного диска (от 80мбайт/с на дешёвых дисках 20-летней давности до 150мб/с на современных обычных). А в нужном (когда потоков много) - либо ничего не даёт (большие файлы и большие блоки по 10мбайт+), либо замедляет (маленькие файлы).

Но два независимых диска дадут х2 ускорение

Каким образом? Поток сначала запросит файлик с одного диска, подождёт, запросит файлик с другого. Тот же самый чистый и незамутнённый 1х против ~1,5х.

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

когда ты зачем-то читаешь последовательно один единственный файл

Почему один единственный? Почему именно читаешь? Если средняя операция над одним файлом не менее 2 блоков мозайки (например целых нереальные 32Кб), тогда ускоряется что угодно и в любых сценариях. А если меньше 1 блока, тогда это будет работать ровно так же, как ты предлагал. Проблема только если размер между 1 и 2 блоков, но каковы шансы?

Хотя опять же, какая проблема? Если диски свободны, тогда время будет примерно то же, просто оба дёграть вместо одного. А если там трешак в 100 потоков на диск, тогда опять же без разницы - что 1 диск, что 2 диска, между чтением 1 и 2-ого блоков один хрен кто нибудь напихает десяток операций и без разницы тот же это диск или другой.

Не, серьёзно, тебя совсем не напрягает что все сложные РАЙД-конфигурации, используемые в продакшене, по сути мозаичные? Но при этом буквально никто не хочет заниматься разбрасыванием файликов по дискам. А ведь попытки были! Есть какая то fuse-приблуда, логически объединяющая 2 физические ФС, только её сделали, забили и забыли.

523 комментария

вот такие у нас на лоре мини-новости! :о)

А на макси-новости обычно комментарии отключают, поэтому это кажется, что 500+ комментариев это много.

Каким образом? Поток сначала запросит файлик с одного диска, подождёт, запросит файлик с другого

Однопоточная скорость диска неинтересна, они нигде не нужна почти.

А если там полный трешак по 100 потоков на диск, так тут вообще без разницы как их рассаживать

Я выше объяснил в чём будет разница. У тебя либо 100 потоков на рейд, которые превращаются в 100 потоков на каждый диск, либо 100 потоков на 8 независимых дисков, которые распределяются по 10-15 на диск.

Если средняя операция над одним файлом не менее 2 блоков мозайки (например целых нереальные 32Кб), тогда ускоряется что угодно и в любых сценариях.

Блок 32к, 2 блока 64к? Хорошо, на одном диске у тебя уйдёт в среднем 10мс на позиционирование + ожидание нужного поворота диска и 0.6мс на собственно чтение. На рейде из двух у тебя уйдут всё те же 10мс на позиционирование + ожидание нужного поворота и 0.3мс на чтение по 32кб с каждого. 10.3 против 10.6 - выиграл целых 3% времени, ценой того что занял оба диска работой вместо одного. Эффективная скорость в расчёте на один диск упала почти в 2 раза.

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

Разбрасывание файлов по дискам избыточности не даст, если там только не мирроры везде, а миррор почти в 2 раза дороже чем raid6.

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

Есть какая то fuse-приблуда, логически объединяющая 2 физические ФС, только её сделали, забили и забыли.

Так оно и не нужно. Проще в приложении прописать что объекты с чётными серийными номерами класть на первый том, с нечётными - на второй.

Потому что рейды делают не для скорости

Что за бред? Рейд делают по разным причинам. В том числе и для скорости. Это офигенный буст! Особенно во времена HDD. Иначе как ты объяснишь RAID0? или Иначе как ты объяснишь RAID10?

Ты походу рили теоретик.

Для рандомного доступа - решает плохо. 8 независимых дисков при правильном балансировании нагрузки на них дают восьмикратную скорость от одного диска. RAID0 из восьми дисков - двух-трёх-четырёхкратную, даже последнее вдвое хуже чем отдельные диски.

Для рандомного доступа Рейд0 дает лучше результат чем без рейда.

И этому есть техническое объяснение.

И прирост скорости линейный, 8 дисков дает восьмикратный прирост, 16 дисков, дает 16-и кратный прирост.

Иметь бэкапы кажется накладным ровно до того момента, как они понадобятся.

бекапы не делают только те кто ничего не терял

О, у кого-то в дебиане криокамера протекла. Мне казалось что разработчики дебиана куда в более надёжных криокамерах. До них глобальное потепление добралось? Или электричество кто-то выключил?

RAID0 я уже объяснил - это на 90% чья-то глупость, когда его воткнули не к месту, и на 10% чья-то лень сделать что-то более нормальное, несмотря на осознание порочности этой штуки.

RAID10 - норм благодаря миррорам, но во многих случаях всё так же воткнут не к месту.

Ты походу рили теоретик.

Ты походу «рили» оправдываешь ещё раньше приписанный к твоему аккаунту комментарий «идиот».

RAID0 я уже объяснил - это на 90% чья-то глупость, когда его воткнули не к месту, и на 10% чья-то лень сделать что-то более нормальное, несмотря на осознание порочности этой штуки.

Это ты так подумал? А аргументы будут адекватные?

Или ты из теоретиков, что думают, что инструмент диктует условия?

Ты походу «рили» оправдываешь ещё раньше приписанный к твоему аккаунту комментарий «идиот».

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

Я выше объяснил в чём будет разница. У тебя либо 100 потоков на рейд, которые превращаются в 100 потоков на каждый диск, либо 100 потоков на 8 независимых дисков, которые распределяются по 10-15 на диск.

Тут может крыться косячок. Мозаичка гарантированно размазывает каждый мегабайт по всем 8 дискам и 100 потоков на каждый диск запросят не по 1М а по 128К и в 8 раз быстрее освободят их. А вот ты рискуешь что все 100М (а не по 12,5М) упадут на один единственный диск.

И риск тут вот нихрена не нулевой. У меня торренты раньше по 3 дискам вручную раскидывались, так вот при раздаче ~400 штук в теории нагрузка должна была отбалансироваться, а на практике была чудовищно рваной и почти всегда сваливалась на 1 конкретный. Почему ты думаешь, что с высоконагруженным веб-сервером не произойдёт того же из за какого нибудь ЛОР-эффекта. Ну да, ты балансировал-балансировал, но вот именно в этот вечер вот эта тема хайпанула, а её файлы лежат на диске 3 и только на диске 3. Бежим и срочно перетасоваем на лету?

Блок 32к, 2 блока 64к? Хорошо, на одном диске у тебя уйдёт в среднем 10мс на позиционирование + ожидание нужного поворота диска и 0.6мс на собственно чтение. На рейде из двух у тебя уйдут всё те же 10мс на позиционирование + ожидание нужного поворота и 0.3мс на чтение по 32кб с каждого. 10.3 против 10.6 - выиграл целых 3% времени, ценой того что занял оба диска работой вместо одного. Эффективная скорость в расчёте на один диск упала почти в 2 раза.

Не, ты же так хочешь многопоток! А значит если операция потребует 2 блока, то между ними шедулеру накидают длинную очередь из других потоков и на одном диске ты получишь 10мс на позиционирование + 0,3мс на чтение + 10мс на позиционирование + 0,3мс на чтение. И ещё плюсом ожидание других таких же хаотичных запросов в очереди. И мозаичка здесь отработает идентично твоему разбросу. Её преимущество, как я писал выше - в простом и эффективном балансировании нагрузки сразу на все диски.

Здесь вообще надо смотреть на дисковые кеши, алгоритм его врутренего использования, твикинг шедулера, в идеале агресивная и сверхдлинная очередь чтобы соборать кучу запросов со всех 100 потоков и потасовать их какое то время пока не прорисуется оптимальный маршрут головок. Или сверхагресивное кеширование, типа запрос был на 3*4К блока, но мы читаем оптом всю дорожку/сектор на ~10М и пусть пока полежит в кеше, вдруг запрос всё таки придёт.

А если всё таки потоков мало, а файлы крупные - преимущество мозаички очевидное. Этот способ позволяет прочитать файл быстрее чем с 1 единственного диска. А если файлы мелкие, то они что так, что так попадают на 1 диск. Тут просто надо грамотно выбрать оптимальный размер блока чередования.

Мозаичка гарантированно размазывает каждый мегабайт по всем 8 дискам и 100 потоков на каждый диск запросят не по 1М а по 128К и в 8 раз быстрее освободят их.

А какой вообще размер блока по умолчанию в рейде?

Никогда не задумывался на эту тему)

на каждый диск запросят не по 1М а по 128К и в 8 раз быстрее освободят их

Не в 8 а в 1.1, поскольку 90% занятого времени будет ездой головок, которая не ускоряется.

А вот ты рискуешь что все 100М (а не по 12,5М) упадут на один единственный диск.

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

У меня торренты раньше по 3 дискам вручную раскидывались, так вот при раздаче ~400 штук в теории нагрузка должна была отбалансироваться, а на практике была чудовищно рваной и почти всегда сваливалась на 1 конкретный.

Какой канал у раздачи торрентов был?

но вот именно в этот вечер вот эта тема хайпанула, а её файлы лежат на диске 3 и только на диске 3.

Если речь про какую-то одну тему то её файлы просто в кеше (в оперативной памяти или ещё каком, предусмотренном на раздающем сервере) в итоге окажутся и всё норм. Чтобы реально случился перекос, нужно чтобы много разных файлов такими одновременно оказались и всем им повезло оказаться на одном диске. Шансы такого весьма малы, ну а даже если реализуются - лучше пожертвовать этим очень редким случаем ради того чтобы всё остальное время иметь производительность 2-3 больше чем raid0.

А значит если операция потребует 2 блока, то между ними шедулеру накидают длинную очередь из других потоков

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

Или сверхагресивное кеширование, типа запрос был на 3*4К блока, но мы читаем оптом всю дорожку/сектор на ~10М и пусть пока полежит в кеше, вдруг запрос всё таки придёт.

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

Этот способ позволяет прочитать файл быстрее чем с 1 единственного диска.

Я с этим и не спорил, но не считаю это существенным случаем.

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

Их для много чего делают. Но обычно там суммирование объёма + избыточность одновременно, а чтобы это не было так уныло по скорости - слой чередования тоже присутствует. Без него есть только рейд0 и рейд1, и то рейд0 без чередования это опция для извращенцев и LVM.

если там только не мирроры везде, а миррор почти в 2 раза дороже чем raid6

И это абсолютно другой вопрос. Дублирование данных и этот некий «контроль чётности» требует оверхеда как по числу дисков так и по времени, но тем не менее, все эти рейды умудряются быть не медленней (а обычно быстрее) 1 диска. И этот эффект исключительно заслуга чередования. Суммирование объёма, зеркалирование даных и запись кодов коррекции ошибок совершенно точно не дадут ускорения.

Проще в приложении прописать что объекты с чётными серийными номерами класть на первый том, с нечётными - на второй.

Ни в коем случае! Не хватало ещё приложению разбираться с типом и конфигурацией накопителей! Это задача менеджера томов ОС, ФС, подсистемы i/o. А если приложение такое умное и продвинутое - пусть работает с блочным устройством напрямую, в обход файловой абстракции.

Я не отстану)) Может с 100 раза дойдет до тебя какую ты глупость пишешь.

Не в 8 а в 1.1, поскольку 90% занятого времени будет ездой головок, которая не ускоряется.

Скорость работы 8 дисков в рейде х8 Буквально в 8 раз. Не 99%, не 10%, не 55%, а именно 800% прирост скорости.

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

Ты хоть для теста собери рейд и посмотри на скорость. Ты же реально позоришься.

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

Невозможно даже в теории. Ты не сможешь так синхронизировать работу с дисками как в рейде.

Для ОС диск в рейде является одним диском и работает он как с одним диском. Когда 8 дисков отдельно, это 8 дисков. И работа будет как с 8 дисками.

Как бы ты не заморачивался скриптами и программами, это будет на порядки медленней чем в рейде.

Я с этим и не спорил, но не считаю это существенным случаем.

Да ты в начале комментария пишешь про это.

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

Сис-в инит легко при желани делал это одной строчкой в fstab, монтирование происходило раньше всего остального, а софта, требующего чтобы из /tmp не исчезали папки, тогда не существовало.

А какой вообще размер блока по умолчанию в рейде? Никогда не задумывался на эту тему)

Очевидно, сконфигурированный? В случае LVM - задумывался на практике. Это прописывается при создании. Жаль что сам LVM - костыльное убожество, не позволяющее сшивать разные диски с асиметричным чередованием. Могли бы придумать что нибудь на эту тему.

Их для много чего делают. Но обычно там суммирование объёма + избыточность одновременно, а чтобы это не было так уныло по скорости - слой чередования тоже присутствует. Без него есть только рейд0 и рейд1, и то рейд0 без чередования это опция для извращенцев и LVM.

Согласен.

RAID для

1.Повышение скорости

2.Повышение отказоустойчивости

3.Повышение управляемости

4.Увеличение емкости разделов

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

Я не согласен с тем, что RAID0 это плохо и он не должен существовать.

Ни в коем случае! Не хватало ещё приложению разбираться с типом и конфигурацией накопителей! Это задача менеджера томов ОС, ФС, подсистемы i/o. А если приложение такое умное и продвинутое - пусть работает с блочным устройством напрямую, в обход файловой абстракции.

База. Я в ахере от того что он пишет.

Рейд0 не надежен, а кидать данные вручную или приложением на 8 дисков это надежно.

Рейд0 медленно. А программой быстро.Ведь в рейде головки ездят медленно, а головки 8 дисков ездят быстро(лол ну так получается у него)

Взаимоисключающие параграфы в одном комментарии, раз за разом.

Очевидно, сконфигурированный?

Всегда пользуюсь значения по умолчанию, отсюда и не помню)

и то рейд0 без чередования это опция для извращенцев и LVM

Это JBOD. Именно то, что могли сделать в UNIX V6 ещё в 1971, вместо /usr/bin и /usr/sbin.

Не в 8 а в 1.1, поскольку 90% занятого времени будет ездой головок, которая не ускоряется.

128К хаотичного чтения (32 блока ФС! Или до 256 блоков устройства!! Это вот ни разу не 1 запрос и точно не 1 позиционирование головки!!!) ровно в 8 раз быстрее 1М хаотичного чтения. Тут даже не важно в какой доле соотносятся задержки шины, позиционирование и чтение/запись с дорожки.

Но при нормальной балансировке нагрузки

Боюсь тут как с чистой водой. Это ведь так просто, вот только на Земле она отсутствует. Нужен простой, эффективный и универсальный алгоритм на все случаи а не экстрасенсорный тест по размещению файликов на будущее. Или предлагаешь отдельный демон сборки статистики и фоновой балансировки вдогонку изменяющейся ситуации? Хочешь его написать и отладить для продакшена? А в аппаратном исполнении слабо?

Какой канал у раздачи торрентов был?

Маленький. Не более 5% скорости 1 диска. Причём «счасливый» диск моргал всю ночь, а «несчасливые» переодически вообще на парковку вставали. Или просто помаргивали по ~100Кб в минуту.

Если речь про какую-то одну тему то её файлы просто в кеше

Не, давай не будем кеш приплетать. А то так договоримся что нужно брать bcashe с рейд1 на ссд+хдд и ещё zfs/btrfs сверху.

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

А почему нет? Вот какой нибудь веб-хостинг. Утром пользователям нужно такси, погода и карты, днём что нибудь по работе, а вечером заказ пиццы и скидки по магазинам. И что, каждую тему размазывать вручную по всем дискам? На уровне каждого сайта? Брррр.... А в понедельник и субботу массовые предпочтения ещё сильнее колеблются.

А если массив данных веб-версии яндекс-карт/2гис. Ну там же явно будут более и менее запрашиваемые квадраты. И что теперь, центр города дробить с ручной раскидкой подквадратов, а всякие СНТ и сёла кидать отдельными пачками?

Шансы такого весьма малы, ну а даже если реализуются - лучше пожертвовать этим очень редким случаем

Это хаотичный процесс и статистика больших чисел. Это значит что при несущественной теоретической вероятности эти случаи будут происходить регулчрно, но что ещё хуже - регулярные случаи начнут группироваться в серии «плохой погоды» и прочих стихийных бедствий. А ты ещё не предложил никакого автоматического алгоритма размазывания данных и балансировки нагрузки.

чтобы всё остальное время иметь производительность 2-3 больше чем raid0

Да не будет она выше! Как раз не ниже, но с некоторой вероятностью дёрнуть 2 устройства там, где 1 справилось бы за то же время. Только дергадации производительности под многопотоком не будет, я описывал выше почему.

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

Это если 1 операция приходит и он может немного подождать и скомпоновать в очереди запросы подряд. А если в очередь стучится много потоков, то очередь переполнится прежде чем появится что компоновать. А там ещё таймеры деллайна «помогут» делать работу качественней.

напомню, рейд не ради скорости а ради надёжности

Это только рейд1 такой. В других добились ускорения относительно 1 диска.

Я не согласен с тем, что RAID0 это плохо и он не должен существовать.

Я не говорил что рейд0 это плохо. Он вообще эталонно предполагает чередование а значит максимальную скорость при максимальном суммарном объёме.

Но есть же ещё простое линейное суммирование томов, это тоже как бы рейд0, только без ускорения.

Ни в коем случае! Не хватало ещё приложению разбираться с типом и конфигурацией накопителей! Это задача менеджера томов ОС, ФС, подсистемы i/o.

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

Все эти стремления изолировать/абстрагировать приложение от железа имеют только одну цель: упростить работу кодерам/админам и её цену (их зарплату). Когда приложение пользуется железом, зная какое железо под какие его потребности лучше подходит - всё получается лучше.

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

Тоже можно, но штатная файловая система как раз часто вполне годится под любые цели (если это не cow-тормоз какой).

Я не говорил что рейд0 это плохо.

Не ты, а firkax который рассказывают про ненужность рейдов.

128К хаотичного чтения (32 блока ФС! Или до 256 блоков устройства!! Это вот ни разу не 1 запрос и точно не 1 позиционирование головки!!!) ровно в 8 раз быстрее 1М хаотичного чтения.

Ты забыл уточнение: 128К хаотичного чтения блоками по 4К или 1М хаотичного чтения блоками по 32К. И эти две задачи будут уже примерно одинаковое время выполняться, потому что и там и там надо будет 32 раза позиционировать головки. Вместо 4К и 32К можешь подставить что-то другое в пропорции 1:8, результат не особо изменится.

Хочешь его написать и отладить для продакшена? А в аппаратном исполнении слабо?

Любой http-сервер раздачи статичи и псевдорандомное раскидывание файлов по всем дискам справятся в большинстве случаев.

Маленький. Не более 5% скорости 1 диска. Причём «счасливый» диск моргал всю ночь

Ну в том и дело. Поставил бы канал в суммарную скорость всех дисков - увидел бы что загружены все близкими нагрузками (около 100%). А у тебя раздатчик отрезал лишних клиентов из-за того что они в канал не влезали и по факту видимо раздавал только один файл с норм скоростью.

Не, давай не будем кеш приплетать.

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

А почему нет? Вот какой нибудь веб-хостинг. Утром пользователям нужно такси, погода и карты, днём что нибудь по работе, а вечером заказ пиццы и скидки по магазинам. И что, каждую тему размазывать вручную по всем дискам? На уровне каждого сайта? Брррр.... А в понедельник и субботу массовые предпочтения ещё сильнее колеблются.

Как думаешь сколько серверов в яндекс-датацентре обслуживают карты? Итд.

вручную

Не вручную а закодено в приложениях. В данном случае - скорее всего не в тех даже что на прод серверах запущены, а в тех, которые их автоматически разворачивают/настраивают.

Это если 1 операция приходит и он может немного подождать и скомпоновать

Не надо ничего ждать, пришёл запрос на чтение 10 блоков подряд - он так и идёт дальше и ничего в него в середину не вставляется.

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

Покажи где такое реализовано. Аж стало интересно как это сделали и какими усилиями.

Да и поржать тоже хочется.

Все эти стремления изолировать/абстрагировать приложение от железа имеют только одну цель: упростить работу кодерам/админам и её цену (их зарплату). Когда приложение пользуется железом, зная какое железо под какие его потребности лучше подходит - всё получается лучше.

А-а-а-а вот оно что. Вот дураки.

Нет бы на ассемблере все программировали, понапридумывали технологий)))

З.Ы. Так и будешь бояться ответить красноносый?

Разбираться там не с чем, все тома симметричные, и по ним надо поровну раскидать. Либо тома несимметричные - но такое можно сделать только если

Ну нифига себе... А если тома ссд? А если тома - сетевая шара? А если это кластер? А если наоборот микроСД на одноплатнике? А всё это в произвольных сочетаниях и особо извращённых конфигах с невменяемыми техзаданиями?

Все эти стремления изолировать/абстрагировать приложение от железа имеют только одну цель: упростить работу кодерам/админам и её цену

Не, это стремление запихать задачу в ПЦ сложный и узкоспециальный чёрный ящик - усложнить работу кодерам и админам и набить цену. А грамотно спроектированная система, логично разбитая на блоки с понятной работой и предсказуемым поведением - ну да, это упрощает всем работу и снижает цену обслуживания.

если это не cow-тормоз какой

Иногда именно CoW и нужен.

Ты забыл уточнение: 128К хаотичного чтения блоками по 4К или 1М хаотичного чтения блоками по 32К. И эти две задачи будут уже примерно одинаковое время выполняться

С.м. тему «ФС как слой абстракции». Приложение запросит 4К блоки и именно в таком виде диск и получит запрос на весь 1М. Слой рейда тоже ничего компоновать в пакеты не станет, просто 4К блоки сначала пойдут на 1 диск, а потом на другой.

результат не особо изменится.

С.м. практические тесты.

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

На примере моих торрентов и данных карт - абсолютно провальный подход. 100% гарантия образования анклавов горячих и холодных данных если у тебя нет либо очень умного и внимательного либо эффективного как топор метода размазывания этих анклавов.

Поставил бы канал в суммарную скорость всех дисков - увидел бы что загружены все близкими нагрузками (около 100%)

Усугубил бы проблему. В моей коллекции порядка 10 раздач были с рейтингом больше 10, и только 1 из них размером больше 100Гб. Если бы я увеличил канал угадай с 3 раз какая именно раздача забрала бы на себя 80-90% и/о. И совершенно случайно есть техническая причина, почему эти 100+ Гб из 2,5Тб должны лежать на одном диске.

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

На реальной системе размер кеша не сопоставим со скоростью приличного рейд-массива. Забьётся за секунды, а через десяток дропнется и перезапишется. К тому же на чтение может работать только опережающий режим с агрессией, а так скорее всего никто не делает.

Как думаешь сколько серверов в яндекс-датацентре обслуживают карты? Итд.

О! Там наверняка на входе большой и сложный балансировщик по дата-центрам а в них куча серверов, а на серверах массивы ссд. Причём мне кажется выбор мозаичного рейд0 был бы довольно хорошим под эту задачу. Может я в чём то и ошибся, но точно не в том, что никто не будет балансировать данные на уровне отдельных дисков. В лучшем случае на уровне регионов картографирования, расквартированных на отдельных серверах.

пришёл запрос на чтение 10 блоков подряд - он так и идёт дальше и ничего в него в середину не вставляется.

А если не 10 блоков подряд а 10 раз по 1 блоку? Ну, ДОС реально послал бы диску 10 запросов. Ядра 00-10-х предлагали 3-4 планировщика, каждый из которых хорош для определённого типа нагрузки. Был там вариант с высокими задержками, как раз для сглаживания хаотичного многопотока. Был и наоборот, для попытки выдать данные с минимальными задержками. Сейчас всё свели к одному универсальному шедулеру, но там вроде есть много настроек (и много паралельных очередей). Короче не факт что не накидают между и точно не факт что не подождёт прежде чем эти 10 запросов передать диску.

При завершении процесса система закрывает все его файлы. Система могла бы те файлы, которые в /tmp не только закрывать, но и удалять. И никакой таймер бы не понадобился.

Привязка времени жизни файла к времени жизни процесса – идея неплохая. Только создавать временные файлы может один процесс. Подхватывать – другой. И при этом после всего они не перестанут быть временными. Это не всегда работает именно так.

Было бы лучше, если б можно было назначить политику хранения временного файла. На выбор. И пусть ШляпаД шуршит. Но, как было сказано ранее, что над ШлапаД «не дураки» работают. Хи-хи.

создавать временные файлы может один процесс. Подхватывать – другой.

В этом случае пусть пайпы используют. Что такое «подхватывает»?

Да что угодно. Добавлять какие-то ограничения – усложнять разработку.

Это проблема на SSD?

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

Кэш ядра рано или поздно попадает на носитель. А это или махание головками, или расход количества перезаписей ячейки.

чтобы при перезагрузке (независимо от причины) продолжить работу с временными файлами

Для этого есть /var/tmp.

потому что паттерн использования такой. я например /tmp/ вообще редко очищаю.

А я вообще не чищу. Но, иногда, происходит перезагрузка.

потому что tmpfs лишняя сущность

ну блин, ну тут вы дали ... стране гугля! :о)