blacklion79

Жаль, жаль. Зная отношение nVidia к Open source, это ни к чему хорошему для пользователей этих прекрасных сетевых карт не приведёт :-(

А теперь добавьте в анализ на сколько менее эффективным был при этом системный кэш. Без оценки всех уровней кэширования эти числа ничего не значат.
Несомненно, PrimoCache работает. Вопрос же не в его эффективности а в эффективности системы в целом. Кстати, хитрейт 17.8% это вообще ни о чём. На тех системах, где мне просто посмотреть (см. выше в другой ветке про торренты) я вижу 95% штатными средствами. На винде… Хмм… Надо поискать… Нашёл только моментальные показатели, там всё болтается на уровне 100%, но это фиговые показатели, хотелось бы, конечно, общее число байтов прочитанных из кэша и мимо кэша с момента старта системы. Пока не могу найти.
И, да, отложенная запись — это, повторю в который раз, — лотерея. И об этом знают и честно предупреждают авторы PrimoCache, за что им отдельный респект, что инженеры у них главнее маркетологов. Могли бы умолчать.
А красота идеи… Ещё во времена DOS 6.2 у MS была такая штатная утилита вообще-то (smartdrv). Сейчас, повторю, я на 95% уверен, что это не нужно, так как система и сама отлично справляется. Т.е. идея-то красивая, спору нет, но, во-первых, она стара примерно как иерархия памяти у вычислительной системы и, во вторых, очень трудно сделать правильно, множество тонкостей.

И, собственно, про deferred write, с которого и начлася весь этот разговор про кэширование, сами авторы PrimoCache пишут:

With the Defer-Write feature, PrimoCache can avoid the redundant writes and reduce wear on SSDs, thus prolonging the lifespan of SSDs. Of course, Defer-Write comes with a risk that data may be lost on system crashes or power failures. It is recommended that you may only enable Defer-Write on volumes where temporary, unimportant or reproducible data is to be stored.

.
Молодцы, честные.

Вот что у 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 не может её ускорить.
РЕАЛЬНАЯ работа — это РЕАЛЬНЫЕ тесты, причём двойные-слепые.

Загрузка винды — нет, понятно почему. Приложений — лучше эти приложения смогут больше памяти использовать.
Ещё раз: это кеширование в RAM. Технология понятная, с понятными плюсами-минусами, но это не ускорение записи на SSD.

Ну какую реальную? Это кеширование в RAM.

У меня в одной некритичной машине (траффик-генератор для сетевых экспериментов) 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 часов.
Вам оно точно мало?

Кстати, контроллеры FireWire умели делать (крохотные) белые списки ID устройств, что позволяло решить эту проблему (произвольному девайсу не давали DMA, а если пользователь явно разрешил — он сам себе злобный буратино), но во ВСЕХ OS это было или вообще не реализовано или отключено, для удобства пользователей :-)

Этой новости примерно столько же лет, сколько спецификации TB. Как только стало известно, что там вытащен наружу PCIe — так сразу все, кто помнил FireWire, переглянулись и понимающе улыбнулись.
Ничего, скоро в вашем USB4.

Сколько там всего, 1.4 миллиарда?
Миллион там только в Бангалоре работает, как раз каждый и подписался, модно же.