LINUX.ORG.RU

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

 , , , ,


1

5

Разработчик Debian Лука Боккасси анонсировал переход Debian к использованию tmpfs в /tmp и к очистке /tmp и /var/tmp по таймеру по умолчанию, начиная с Debian 13 “Trixie”.

В новых системах файлы в /tmp будут либо исчезать вместе с прежним экземпляром tmpfs в памяти после рестарта, либо будут удаляться ежедневно по таймеру, если они старше 10 дней, а файлы в /var/tmp будут удаляться только ежедневно по таймеру, если они старше 30 дней. Пакеты openssh и tmux были модифицированы с целью сохранения своих временных файлов в /var/tmp в качестве исключения. В системах, которые будут обновляться до Debian 13 “Trixie”, старое поведение /var/tmp сохранится.

В то время, как в большинстве других дистрибутивов давно перешли на использование tmpfs в /tmp, в Debian не спешили этого делать. Сейчас разработчики Debian (Michael Biebl и Luca Boccassi) возобновили одну из таких дискуссий 2020 года, в которой разработчик из Canonical (Eric Desrochers) пожаловался на проблему несоответствия тогдашней реализации /var/tmp в Debian тому, как работает systemd, несмотря на то, что патч был опубликован ещё в 2012 году. Таким образом, было принято решение привести поведение системы при работе с этими директориями к общепринятому в systemd и в большинстве других дистрибутивов.

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



Проверено: hobbit ()
Последнее исправление: Virtuos86 (всего исправлений: 7)
Ответ на: комментарий от zg

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

When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp…) and wrote files to those new directories because their original disk was out of space.

Интересно. То есть уже на той первой машине в /usr были системные файлы в дополнение к user директориям.

When they got a third disk, they mounted it on /home and relocated all the user directories to there

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

Это не возражение тебе, а просто наблюдение: мне кажется, нельзя сказать что /usr - это изначально пользовательская директория. То есть она возможно была в чьем-то там воображении, якобы до установки второго диска, в некую одну машину. Это были произвольные названия и случайное расположение файлов еще на этапе разработки, то есть до того, как unix увидел свет.

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

Это не «этапы разработки», это эксплуатация системы с доработкой по ходу возникновения новых потребностей. В разные времена было разное расположение файлов.

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

Интересно. То есть уже на той первой машине в /usr были системные файлы в дополнение к user директориям.

С чего ты это взял? Пока место на первом диске не закончилось ничего системного в /usr не писали. То есть была вполне себе логичная иерархия файловой системы, пока не начали решать проблему нехватки места костылями. С тех пор UNIX оброс гораздо большей массой костылей. При этом второй и третий диски были точно такими же, как и первый и можно было бы сделать RAID. Но костыль оказался дешевле и сердитее.

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

можно было бы сделать RAID. Но костыль оказался дешевле и сердитее.

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

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

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

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

Более того, пойди они другим путём, иерархия директорий UNIX не была бы на столько раздутой, а примерно такой:

/
/dev
/bin
/sbin
/lib
/tmp
/etc
/usr  (домашние директории пользователей)

Было бы только то, что выше и со временем можно было бы отказаться и от /sbin. Например в Xenix /sbin уже не было https://www.youtube.com/watch?v=YUxaLP6bI00 (7:22) Или можно посмотреть на сборки некоторых программ, распространяемые в тарболах. Там примерно та же структура директорий в миниатюре. Согласись, что так было бы лучше.

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

Я не пойму, ты контраргументы приводишь (не похоже), или вообще не понял что я написал?

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

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

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

Можно развернуть мысль? Что-то в толк не возьму, за счёт чего это должно быть медленнее.

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

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

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

Или вот другой пример: положи на два диска два больших файла и читай их с помощью dd в null - они будут читаться почти на максимальной скорости (если не фрагментированы). Положи их на один raid0 из тех же двух дисков - и они начнут постоянно ездить головками от одного файла к другому и всё станет медленнее.

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

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

Я не пойму, ты контраргументы приводишь (не похоже), или вообще не понял что я написал?

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

Это не менее надёжно, чем раскидать файловую иерархию системы по точкам монтирования. Ну вот умер у тебя весь /usr и система встала, что ты будешь делать после замены второго диска? Либо начнёшь восстанавливать /usr из бэкапа, либо начнёшь переустанавливать всю систему. Если у тебя RAID0 или просто каждый последующий диск продолжает предыдущий список секторов, то в случае такого же выхода из строя второго диска ты опять же, либо восстановишь всё из бэкапа, либо полностью переустановишь. Современных требований надёжности, когда с одним умершим диском данные в RAID не теряются, тогда никто не ставил. А вот возможность расширять дисковое пространство и увеличивать скорость доступа к тогдашним медленным дискам была бы действительно прорывом.

zg
() автор топика
Последнее исправление: zg (всего исправлений: 3)
Ответ на: комментарий от firkax

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

Так чем больше дисков будут работать параллельно, тем быстрее будет запись и чтение. Давай рассмотрим другой RAID. У тебя 8 одинаковых дисков. Каждый байт данных разбивается на 8 бит, которые записываются на эти 8 дисков по отдельности. В результате параллельно читая по одному блоку данных с одного и того же места каждого диска ты получаешь восемь блоков данных за время чтения одного. То же самое и при записи. Если добавить девятый диск, на нём можно сохранять бит чётности, что увеличит надёжность и позволит продолжать работу после выхода из строя любого одного диска из девяти.

zg
() автор топика
Последнее исправление: zg (всего исправлений: 3)
Ответ на: комментарий от firkax

А ты пользовался RAID0 хоть раз?

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

тут я конечно прифигел)) Конечно нет. RAID0 будет быстрей всегда чем не рейд. Вообще RAID0 самый быстрый из рейдов. Его как раз чаще всего ради скорости и используют.

З.Ы. Знал бы ты как быстро работает RAID0 на SSD. 10ГБ/сек это нечто. Жаль такая скорость для меня излишняя))

это НЕ надёжно

Почему ты так решил? Надежность это свойство построенной системы.

RAID0 вполне может быть надежным, если удовлетворяет потребностям.

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

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

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

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

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

Откуда у тебя возьмётся езда головок в разные стороны, когда ни на одном диске в отдельности у тебя нет ни одного полного байта информации? Такой RAID 8 или 8+1 это как один большой диск с одним набором блинов и головок и с увеличенным в 8 раз размером блока, который читается/пишется за то же самое время, как и один обычный блок одного физического диска. Головки будут двигаться абсолютно синхронно. Просадки производительности, по сравнению с одним диском, не будет. Максимум что будет - деградация ускорения производительности до производительности одного диска на большом количестве маленьких файлов. То есть медленее одного диска никогда не будет.

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

Откуда у тебя возьмётся езда головок в разные стороны

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

Головки будут двигаться абсолютно синхронно.

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

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

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

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

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

Как и у одного единственного диска.

И это плохо. Они могли бы двигаться не синхронно, а каждая к своим данным и прочитать их в итоге быстрее, например 8 запросов (если повезёт и они окажутся к разным дискам) выполнять одновременно.

Откуда возьмётся такое везение, когда в классическом UNIX каждый диск - это отдельная точка монтирования? У нас, скорее всего, некоторые диски будут просто простаивать большую часть времени, в то время как другие будут работать с большими объёмами данных в одной из подветок дерева директорий, например в /usr.

А так они (если только речь не о последовательном чтении больших файлов) будут ехать сначала по первому запросу, потом по второму, потом по третьему, в итоге почти в 8 раз дольше, потому что езда головками при рандомном чтении занимает больше времени чем собственно чтение.

Ну вот если собирать диски в один RAID, в котором каждый последующий диск просто добавляет новые сектора (LBA тогда не было, но логически можно представить как будто они были), можно было бы уже в древнем UNIX 70-х годов параллелить такие запросы чтения/записи. Но, как я уже говорил, было выбрано наименее эффективное решение с множеством точек монтирование, то есть просто костыль.

Можно сделать и гибридное решение и совсем уйти в дебри оптимизации, но мы обсуждаем то, как это было в 70-х.

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

Так мы ведь обсуждаем не универсально идеальное решение для всех случаев. Множество точек монтирования - это наиболее неэффективное решение. Хуже даже трудно представить. Оно лишь простое и сердитое, как и все костыли.

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

Откуда возьмётся такое везение, когда в классическом UNIX каждый диск - это отдельная точка монтирования? У нас, скорее всего, некоторые диски будут просто простаивать большую часть времени, в то время как другие

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

Множество точек монтирования - это наиболее неэффективное решение.

Нет, это решение наиболее эффективное среди тех где нет избыточности. Эффективнее него может быть миррор, но он стоит в N раз дороже (впрочем, ради надёжности хотя бы 2х миррор вполне можно иметь). Raid0 же это тупо способ увеличить размер тома не вдаваясь в детали работы приложения вообще нинасколько.

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

Но ведь тогда ещё и ФС больших тоже не было! Причём с ограничениями начисло файлов вообще и всякое прочее вроде максимальной глубины вложенности. Если почитать ТТХ миниксФС то там вообще не возникает желания объединять диски.

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

Они могли бы двигаться не синхронно

Они в теории даже не могут двигаться синхронно. Диски в рейде работают асинхронно.

А так они (если только речь не о последовательном чтении больших файлов) будут ехать сначала по первому запросу, потом по второму, потом по третьему, в итоге почти в 8 раз дольше, потому что езда головками при рандомном чтении занимает больше времени чем собственно чтение.

Нет. Это не так работает. Как раз всё наоборот. Чем больше дисков, тем меньше задержка. 8 дисков, в 8 раз быстрей отдаст файл, так как одновременно отдаст 8 частей файла.

По сравнению с 8 независимыми - будет и большая.

Как ты это представляешь? )) Как ты один файл раскидаешь на 8 независимых дисков? Вручную?

Это какаято фантазия)

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

Вот только мозаичный рейд0 отлично доказал свою эффективность. Ну да, нужно ездить гловками. Но количество операций головок то же самое, зато делится на 2 исполнителей. Если повезёт то поровну.

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

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

Зачем мне этим вручную заниматься и что делать, когда свойства моих файлов поменяются? Переустанавливать или переформатировать заново? RAID решаети эту задачу автоматически. Для большого количества маленьких файлов берём один вариант RAID, а для больших файлов другой. Наверное можно их даже объединить, создав некий гибрид. Кажется в некоторых файловых системах даже предусмотрена некоторая оптимизация для маленьких файлов. NTFS? Но я настойчиво прошу не забывать, что мы обсуждаем PDP-11 в далёкие 70-е, у которого каждый из жёстких дисков был размером с дискету из нашего детства, а ведь уже и дискет давно нет.

Нет, это решение наиболее эффективное среди тех где нет избыточности. Эффективнее него может быть миррор, но он стоит в N раз дороже (впрочем, ради надёжности хотя бы 2х миррор вполне можно иметь). Raid0 же это тупо способ увеличить размер тома не вдаваясь в детали работы приложения вообще нинасколько.

На запись миррор не эффективнее одного диска. Большая нагрузка на запись снижает выигрыш в скорости чтения. Основным неоспоримым преимуществом миррора является его большая, чем у одиночного диска, надёжность. Для PDP-11 Raid0 или нечто подобное было бы прорывом. Но я уже устал это повторять. Даже из рассказа Rob Landley видно, что они тупо решали проблему нехватки места на диске. Причём на столько тупо, что тупее некуда. Нет места в /bin? Не беда, у нас есть ещё и директория /usr/bin, которая так же находится в PATH и значит нет разницы куда запихивать очередной бинарник программы или очередную библиотеку в /usr/lib вместо /lib. Примитивно, дёшево, сердито и супер костыльно. Нужно быть совсем уж ретроградом или религиозным фанатиком, чтобы защищать это их тогдашнее решение.

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

Но ведь тогда ещё и ФС больших тоже не было!

Были, причём гораздо больше их трёх дисков по полтора мегабайта вмести взятые. Вот немного переформатированная цитата третьей страницы из https://adaebabbage.wordpress.com/wp-content/uploads/2011/04/comparison_of_file_systems.pdf

File system: V6FS
Maximum filename length: 14 bytes
Allowable characters in directory entries: Any byte except NUL and /
Maximum pathname length: No limit defined
Maximum file size: 16 MB
Maximum volume size: 2 TB (2 × 1024^4 bytes)

V6FS создали в 1972. Rob Landley описывает события после переезда с PDP-7 на PDP-11 «около 1971 года», как он сам сказал. То есть V6FS уже была как минимум в прототипе, если не в готовом виде. Ведь 1972 - это даже не год создания файловой системы, а год выпуска UNIX V6. Причём именно в UNIX V6 костыль с множественным монтированием, судя по всему, и появился в реальном продакшене. Ну и даже если предположить, что V6FS ещё не было, то что было? Было меньше двух терабайт (немыслимый размер, по тем времена), а на сколько меньше? Один терабайт? 256 мегабайт? У них там было три жёстких диска на три сраные дискеты из 90-х.

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

Зачем мне этим вручную заниматься и что делать, когда свойства моих файлов поменяются? Переустанавливать или переформатировать заново?

Причём тут переустанавливать переформатировать? У тебя условно есть разделы /mnt/data0 /mnt/data1 ... /mnt/data7, и уже дело приложения (+симлинков) класть на них файлы в нужном порядке.

RAID решаети эту задачу автоматически

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

На запись миррор не эффективнее одного диска.

Речь везде была про чтение. На запись в большинстве случаев можно забить, её доля в общей работе дисков меньше 10%, а где-то около 1%. Да, есть какие-то специальные случаи, но для них можно специальные решения применять.

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

Ты всё время уводишь разговор в сторону. Перечитай выше о каких годах и о каких дисках идёт речь, а так же о том, какую именно проблему решали Ken Thompson и Dennis Ritchie костылём с множественным монтированием.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

zg
() автор топика
Ответ на: комментарий от firkax

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А если там полный трешак по 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 раза.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я выше объяснил в чём будет разница. У тебя либо 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 диск. Тут просто надо грамотно выбрать оптимальный размер блока чередования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласен.

RAID для

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

zg
() автор топика
Ответ на: комментарий от firkax

Не в 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 диска.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

вручную

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты забыл уточнение: 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 запросов передать диску.

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