Вот что у PrimoCache круто — это кэширование на SSD когда основной диск медленный. Это аналог L2ARC у ZFS и это действительно может быть очень полезно и совершенно безопасно.
Нет, им не всё равно, им дают разные команды (запись с разрешением кэширования и без разрешения), и они обязаны слушаться. Да, некоторые консьюмерские девайсы врут (не слушаются), и, да, это проблема. Конечно диски ничего не знают про файлы, но про каждую команду на запись группы блоков они знают, можно ли её кэшировать или надо давать ответ только после реальной записи. По крайней мере это так с тех пор как в SATA появился NCQ, до этого всё было чуть сложнее на ATA (у SCSI это было всегда).
Ещё раз: или мы слушаемся операционную систему и тогда всё наше кэширование только повторяет то, что уже сделала ОС сама в своих кэшах, или мы ей врём и тогда повышаем вероятность разрушения файловой системы.
Если бы у ОС не было кэша — как у DOS когда-то — то да, всё справедливо. Но нет, современные системы очень эффективно и агрессивно кэшируют все дисковые операции сами. У меня сейчас вот из 32 гигабайт памяти 19 гигабайт занято кэшом — как вы думаете, будет ли лучше, если я отрежу 8 гигабайт и буду кэшировать ещё раз, денржа кучу данных в памяти дважды?
Именно в работе с блоками и кроется подстава.
У любой FS есть два типа операций записи — те, что можно отложить ради увеличения эффективности (пользовательские данные если софт не сказал fsync() или его виндовый аналог а так же некоторые данные необходимые самой FS) и те, что откладывать нельзя, так как именно они обеспечивают целостность структур файловой системы. Любая FS спроектирована таким образом (ну, если не считать багов), что она остаётся в корректном состоянии именно потому что последовательность изменений её внутренних структур выстроена так, что когда все эти записи подтверждаются, то и файловая система не разрушена. Предпринимаются большие усилия на уровне дизайна файловых систем, что бы таких важных записей было поменьше потому что все понимают, что тормоза именно в них. Пример механизма группировки таких операций без риска нарушить целостность файловой системы — Soft Updates в файловой система FFS (я, увы, не знаком с последними достижениями файловых систем на Linux, так что примеров оттуда привести не могу).
В современных OS не бывает записи прямо на диск. Ну, почти не бывает, но, в общем, любая штатная запись проходит через тот или иной системный кэш. Причём, все современные OS (т.е. по сути Windows, MacOS, Linux и *BSD) настраиваются таким образом, что бы не держать свободную физическую память вообще. Как только появляется свободная физическая память — сразу же она отдаётся дисковому кешу. Если есть свободная память — это значит, нет ни тяжёлых программ ни дисковой активности вообще. Так вот, этот системный кэш — он знает про те записи, которые задерживать нельзя, потому что от их успеха зависит целостность файловой системы и драйвер файловой системы ждёт их честного подтверждения. И именно тут могут быть тормоза из-за частого обновления access time, например (а вы ещё не отключили его? А почему? А зачем вам atime, ну если вы вообще заботитесь о выжимании последних капель производительности?). Такую запись надо подтвердить во-первых, честно (т.е. не положить в кэш и подтвердить, а дождаться подтверждения от носителя что, впрочем, у бытовых носителей ничего не гарантирует, но это отдельная история) а, во-вторых, подтвердить быстро (потому что файловая система не делает никаких других операций пока не будет закончена эта).
Так вот, если мы встраиваем дополнительный уровень кэша в RAM (т.е. в непостоянной памяти), на уровне блоков, то у нас есть два пути: Первый путь — быть честными. И все важные (синхронные) записи пускать мимо кэша. Но тогда мы ничего не ускоряем а, скорее, замедляем, так как отъедаем память у системного кэша и данные кэшируются дважды. Один вред. Путь второй — врать. И откладывать даже такие синхронные записи. Ускорение некоторое будет, несомненно. Но вот тут мы играем с огнём — потому что мы врём. И если система рухнет в неудачный момент, то будут потеряны не только пользовательские данные записанные в последние секунды (это может быть и с системным кэшом, это ожидаемо), но и вместо согласованных структур данных файловой системы на диске может оказаться винигрет. Какие-то важные записи пройдут, какие-то нет, причём в худшем случае пройдут более поздние, сделанные в предположении, что предыдущие уже на диске. Так можно потерять гораздо больше, чем последние несколько минут данных. Так можно потерять и очень старые данные, и данные записанные час назад, и что угодно. Стоит ли небольшое ускорение этого? Решать вам. Но понимать это надо.
И есть ещё одна тонкость — так как операционная система и так старается раздуть свой кэш насколько это возможно, а мы теперь кэшируем ещё и блоки прямо с диска в той же памяти, то часть данных получается закэшированной дважды, а кэш системмы становится менее эффективным. Т.е. вообще-то можно получить даже проигрыш в производительности вместо выигрыша.
Вот на что будет интересно посмотреть — как файловые системы адаптируют к постоянным кэшам в памяти, когда NV-DIMM станут обыденностью. Вот тут наработки Rapid Mode и PrimoCache могут здорово пригодиться. Но пока NV-DIMM — серверная экзотика.
Никакой винды, файловая система ZFS с её штатным L2ARC. Выводы — имя терабайты торрентов и даже всего 16 гигабайт RAM, 120 гигов кэша второго уровня погоды не делают вообще никакой. У меня хитрейт в ARC (кеш в памяти) 95%, т.е. 5% чтений — с дисков, остальное уже в памяти. Из этих 5%, проскочивших мимо кэша, второй кэш на 120GB давал хитрейт всего в 10% (т.е. 0.5% относительно всех чтений), только зря SSD запили.
Проблема в том, что такое глубокое кеширование должно быть согласовано на уровне FS, т.е. FS должна про него знать. Иначе однажды мы получим разрушенную FS, так как ожидания и гарантии, которых FS ждёт от диска и которые ей необходимы для поддержания своей целостности, окажутся нарушенными. Если же этот кэш будет поддерживать все гарантии, то он ничего не сможет толком ускорить, так как все записи, которые FS ожидает увидеть синхронными («и система больше не ожидает сохранения изменённых данных, прежде чем они будут изменены вновь») он будет вынужден делать синхронно. А то, что не ожидается синхронным, и так может зависнуть в штатном буферном кэше операционной системы, NTFS, конечно, тупенькая, но не на столько что бы все записи делать синхронными.
Хороший пример встроенного глубокого кеширования — ZFS.
Загрузка винды — нет, понятно почему. Приложений — лучше эти приложения смогут больше памяти использовать.
Ещё раз: это кеширование в RAM. Технология понятная, с понятными плюсами-минусами, но это не ускорение записи на SSD.
У меня в одной некритичной машине (траффик-генератор для сетевых экспериментов) SSD 750 Evo уже год живёт в состоянии 1% времени жизни по SMART и с общим ресурсом записи в 15 раз выше чем гарантийный, потому что он одно время стоял кэшом для торрентов. И ничего, живёт, ничего ему не делается. Но никуда, где будет хотя бы один байт данных, который мне важен (а не просто ядро OS из стандартного дистрибутива) я его не поставлю :-)
Далеко не все, во-первых. Только начальный уровень. Ну и я не писал, что у всех корпоративных так, я писал МОЖЕТ БЫТЬ, и такие примеры вполне есть на рынке.
К тому же, резерв зависит как раз от прошивки. Как и Flash Translation Level.
Ни стоимость пропавших данных, ни потери от простоя техники, ни трудозатраты на новую установку системы гарантия не возместит. А потеря пары сотен вечноубиеннных на фоне суммарных потерь — это так, на уровне статпогрешности.
Эм. Простой – да, неизбежен. Всё остальное – вопрос бэкапов. Если ваши данные стоят денег и ваше время (на установку системы) стоит денег, но вы не делаете бэкапов — значит у вас только иллюзия стоимости этого всего, и никаких реальных потерь у вас не будет.
Это в равной степени относится и к SSD и к HDD и к чему угодно.
Если $200 у вас статпогрешность (т.е., с кажем, меньше 10%), то почему вы не потратили эти $200 на бэкап, что бы при смерти SSD воткнуть другой из ЗИПа, раскатаь бэкап за пару часов и потерять один день данных и пол-дня времени, а не на $2K? Или у вас каждый день данные стоят $2K? Тогда почему у вас не RAID и не корпоративного класса SSD, а дешёвка консьюмерская?
Что-то тут не так.
А это плохой контроллер. Вы не можете записать что-то на один и тот же участок флэша со стороны обычного интерфейса (SATA или NMVe). Записи перераспределяются. Ранние контроллеры могли это делать неоптимально. Контроллеру это очень сложно делать, если одновременно диск полный (записали вовсюда и не делали TRIM) и мало резервированного места (что типично как раз для обычных SSD, у корпоративных может быть до трети объёма спрятано для облегчения жизни контроллера и обеспечения надёжности).
Это на сколько превышает обязательства производителя?
К тому же — 2700 терабайт на 256 гигабайт это 11 тысяч перезаписей практически. И это 5 миллионов секунд непрерывной записи. Для консьюмерского девайса это очень много. Это, скажем, я могу раз в 5 минут сохранять гигабайтную картинку в фотошопе (скан среднего формата с несколькими слоями) в течение 230 тысяч (!) часов. Это 78 лет каждый день по 8 часов.
Вам оно точно мало?
Даже проще — удобно ли пользоваться усилителем, где есть 2 позиции громкости? Нет, очень неудобно.
Удобно ли пользоваться усилителем, где есть 100 позиций громкости, но где громкость удваивается между 32 и 34? Тоже, знаете, как-то не очень. Плохо это спроектированный усилитель. Даже если на 32 он и даёт идеальный звук.
Наличие настроек — не тоже самое, что насчтрйока которая всё КАРДИНАЛЬНО меняет при изменении от 3.2 до 3.4 при полном диапазоне 0-10.
Это очень плохо сделанная настройка, если машина к ней так чувствительна. С инженерной точки зрения плохо сделанная. Изменение на 2% должно не должно приводить к (цитирую) «сильно меняет вкус кофе». Изменение на 2% должно приводить к изменению вкуса на условные 2% (я фиг знает как вкус в процентах мерять, но я уверен, что 2% — это не «сильно»).
Это, повторю, совсем не тоже самое «при этом лишаетесь настроек» и «не можете настроить под себя».
Это как если у гоночной машины есть винт регулировки карбюратора (уж если мы говорим аналогиями, да, я знаю, что там нет карбюратора давно и инжектор не регулируется винтами), у которого 10 оборотов, но мощность машины меняется в два раза при довороте на 10 градусов одного оборота. Нет же! У него для того и есть 10 оборотов, что бы можно было настроить РЕЗУЛЬТАТ на 2% а не в два раза!
Отличие гоночной машины от «гражданской» в том, что у гоночной винт имеет таки 10 оборотов, у гражданской — 1. И гоночную можно настроить на 2%, а гражданскую – только грубо (потому что 1 оборот точно крутить бесполезно). Т.е. ситуация ровно противоположная той, что вы описывает (2% настройки влияют сильно).
Так что, повторю, это очень плохая чувствительность к внешним параметрам.
Плохо не то, что можно настроить температуру и давление, плохо то, что реакция на настройки — резкая, а не плавная.
Про станки тоже, в общем, смешно — именно у профессионального высокоточного станка будет а лимбе сотка а не десятка. И именно профессиональный станок на один доворот маховичка подачи отреагирует гораздо менее драматически, чем станок попроще.
Это удивительный комментарий. Т.е. хорошей считается машина, которая на деле плохая?
Я ничего не знаю про кофе, но я точно знаю, что когда звук усилителя начинает зависеть от чистоты питания и проводов — это ОЧЕНЬ ПЛОХОЙ УСИЛИТЕЛЬ.
Хорошая техника — стабильная техника, с плавным, линейным откликом. Это очень важная характеристика любой техники. Не должно быть никаких атрракторов и прочего, когда изменение входных данных на 0.1% приводит к изменением результатов не на 0.1% :-)
1. фрукты надо есть свежими — а свежие они доступны круглый год
Хорошо жить в Таиланде круглый год. Да и на Шри-Ланке неплохо.
Я ещё хотел спросить у автора статьи, где он(а) вообще взял(а) съедобное манго для сушки в России, особенно в январе-феврале, а тут, оказывается, любые фсвежие фрукты хорошего качества доступны круглый год. Везёт вам.
Ещё раз: или мы слушаемся операционную систему и тогда всё наше кэширование только повторяет то, что уже сделала ОС сама в своих кэшах, или мы ей врём и тогда повышаем вероятность разрушения файловой системы.
Если бы у ОС не было кэша — как у DOS когда-то — то да, всё справедливо. Но нет, современные системы очень эффективно и агрессивно кэшируют все дисковые операции сами. У меня сейчас вот из 32 гигабайт памяти 19 гигабайт занято кэшом — как вы думаете, будет ли лучше, если я отрежу 8 гигабайт и буду кэшировать ещё раз, денржа кучу данных в памяти дважды?
У любой FS есть два типа операций записи — те, что можно отложить ради увеличения эффективности (пользовательские данные если софт не сказал fsync() или его виндовый аналог а так же некоторые данные необходимые самой FS) и те, что откладывать нельзя, так как именно они обеспечивают целостность структур файловой системы. Любая FS спроектирована таким образом (ну, если не считать багов), что она остаётся в корректном состоянии именно потому что последовательность изменений её внутренних структур выстроена так, что когда все эти записи подтверждаются, то и файловая система не разрушена. Предпринимаются большие усилия на уровне дизайна файловых систем, что бы таких важных записей было поменьше потому что все понимают, что тормоза именно в них. Пример механизма группировки таких операций без риска нарушить целостность файловой системы — Soft Updates в файловой система FFS (я, увы, не знаком с последними достижениями файловых систем на Linux, так что примеров оттуда привести не могу).
В современных OS не бывает записи прямо на диск. Ну, почти не бывает, но, в общем, любая штатная запись проходит через тот или иной системный кэш. Причём, все современные OS (т.е. по сути Windows, MacOS, Linux и *BSD) настраиваются таким образом, что бы не держать свободную физическую память вообще. Как только появляется свободная физическая память — сразу же она отдаётся дисковому кешу. Если есть свободная память — это значит, нет ни тяжёлых программ ни дисковой активности вообще. Так вот, этот системный кэш — он знает про те записи, которые задерживать нельзя, потому что от их успеха зависит целостность файловой системы и драйвер файловой системы ждёт их честного подтверждения. И именно тут могут быть тормоза из-за частого обновления access time, например (а вы ещё не отключили его? А почему? А зачем вам atime, ну если вы вообще заботитесь о выжимании последних капель производительности?). Такую запись надо подтвердить во-первых, честно (т.е. не положить в кэш и подтвердить, а дождаться подтверждения от носителя что, впрочем, у бытовых носителей ничего не гарантирует, но это отдельная история) а, во-вторых, подтвердить быстро (потому что файловая система не делает никаких других операций пока не будет закончена эта).
Так вот, если мы встраиваем дополнительный уровень кэша в RAM (т.е. в непостоянной памяти), на уровне блоков, то у нас есть два пути: Первый путь — быть честными. И все важные (синхронные) записи пускать мимо кэша. Но тогда мы ничего не ускоряем а, скорее, замедляем, так как отъедаем память у системного кэша и данные кэшируются дважды. Один вред. Путь второй — врать. И откладывать даже такие синхронные записи. Ускорение некоторое будет, несомненно. Но вот тут мы играем с огнём — потому что мы врём. И если система рухнет в неудачный момент, то будут потеряны не только пользовательские данные записанные в последние секунды (это может быть и с системным кэшом, это ожидаемо), но и вместо согласованных структур данных файловой системы на диске может оказаться винигрет. Какие-то важные записи пройдут, какие-то нет, причём в худшем случае пройдут более поздние, сделанные в предположении, что предыдущие уже на диске. Так можно потерять гораздо больше, чем последние несколько минут данных. Так можно потерять и очень старые данные, и данные записанные час назад, и что угодно. Стоит ли небольшое ускорение этого? Решать вам. Но понимать это надо.
И есть ещё одна тонкость — так как операционная система и так старается раздуть свой кэш насколько это возможно, а мы теперь кэшируем ещё и блоки прямо с диска в той же памяти, то часть данных получается закэшированной дважды, а кэш системмы становится менее эффективным. Т.е. вообще-то можно получить даже проигрыш в производительности вместо выигрыша.
Вот на что будет интересно посмотреть — как файловые системы адаптируют к постоянным кэшам в памяти, когда NV-DIMM станут обыденностью. Вот тут наработки Rapid Mode и PrimoCache могут здорово пригодиться. Но пока NV-DIMM — серверная экзотика.
Хороший пример встроенного глубокого кеширования — ZFS.
РЕАЛЬНАЯ работа — это РЕАЛЬНЫЕ тесты, причём двойные-слепые.
Ещё раз: это кеширование в RAM. Технология понятная, с понятными плюсами-минусами, но это не ускорение записи на SSD.
К тому же, резерв зависит как раз от прошивки. Как и Flash Translation Level.
Эм. Простой – да, неизбежен. Всё остальное – вопрос бэкапов. Если ваши данные стоят денег и ваше время (на установку системы) стоит денег, но вы не делаете бэкапов — значит у вас только иллюзия стоимости этого всего, и никаких реальных потерь у вас не будет.
Это в равной степени относится и к SSD и к HDD и к чему угодно.
Если $200 у вас статпогрешность (т.е., с кажем, меньше 10%), то почему вы не потратили эти $200 на бэкап, что бы при смерти SSD воткнуть другой из ЗИПа, раскатаь бэкап за пару часов и потерять один день данных и пол-дня времени, а не на $2K? Или у вас каждый день данные стоят $2K? Тогда почему у вас не RAID и не корпоративного класса SSD, а дешёвка консьюмерская?
Что-то тут не так.
К тому же — 2700 терабайт на 256 гигабайт это 11 тысяч перезаписей практически. И это 5 миллионов секунд непрерывной записи. Для консьюмерского девайса это очень много. Это, скажем, я могу раз в 5 минут сохранять гигабайтную картинку в фотошопе (скан среднего формата с несколькими слоями) в течение 230 тысяч (!) часов. Это 78 лет каждый день по 8 часов.
Вам оно точно мало?
Удобно ли пользоваться усилителем, где есть 100 позиций громкости, но где громкость удваивается между 32 и 34? Тоже, знаете, как-то не очень. Плохо это спроектированный усилитель. Даже если на 32 он и даёт идеальный звук.
Это очень плохо сделанная настройка, если машина к ней так чувствительна. С инженерной точки зрения плохо сделанная. Изменение на 2% должно не должно приводить к (цитирую) «сильно меняет вкус кофе». Изменение на 2% должно приводить к изменению вкуса на условные 2% (я фиг знает как вкус в процентах мерять, но я уверен, что 2% — это не «сильно»).
Это, повторю, совсем не тоже самое «при этом лишаетесь настроек» и «не можете настроить под себя».
Это как если у гоночной машины есть винт регулировки карбюратора (уж если мы говорим аналогиями, да, я знаю, что там нет карбюратора давно и инжектор не регулируется винтами), у которого 10 оборотов, но мощность машины меняется в два раза при довороте на 10 градусов одного оборота. Нет же! У него для того и есть 10 оборотов, что бы можно было настроить РЕЗУЛЬТАТ на 2% а не в два раза!
Отличие гоночной машины от «гражданской» в том, что у гоночной винт имеет таки 10 оборотов, у гражданской — 1. И гоночную можно настроить на 2%, а гражданскую – только грубо (потому что 1 оборот точно крутить бесполезно). Т.е. ситуация ровно противоположная той, что вы описывает (2% настройки влияют сильно).
Так что, повторю, это очень плохая чувствительность к внешним параметрам.
Плохо не то, что можно настроить температуру и давление, плохо то, что реакция на настройки — резкая, а не плавная.
Про станки тоже, в общем, смешно — именно у профессионального высокоточного станка будет а лимбе сотка а не десятка. И именно профессиональный станок на один доворот маховичка подачи отреагирует гораздо менее драматически, чем станок попроще.
Я ничего не знаю про кофе, но я точно знаю, что когда звук усилителя начинает зависеть от чистоты питания и проводов — это ОЧЕНЬ ПЛОХОЙ УСИЛИТЕЛЬ.
Хорошая техника — стабильная техника, с плавным, линейным откликом. Это очень важная характеристика любой техники. Не должно быть никаких атрракторов и прочего, когда изменение входных данных на 0.1% приводит к изменением результатов не на 0.1% :-)
Хорошо жить в Таиланде круглый год. Да и на Шри-Ланке неплохо.
Я ещё хотел спросить у автора статьи, где он(а) вообще взял(а) съедобное манго для сушки в России, особенно в январе-феврале, а тут, оказывается, любые фсвежие фрукты хорошего качества доступны круглый год. Везёт вам.