Пока все хорошо на обычных десктопных без ECC.

ты проверял црц всех 10тб данных?

И скраб и rsync.

??? как скраб определит, данные, которые были испорчены в памяти и записаны такими на диск?

Поверь, отсутствие ECC - это фигня, по сравнению с атаками на незащищенную SATA шину.

Только если испорчены при зеркалировании, когда уже записана одна копия.

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

Совпадения по времени с постами на форумах, раньше никогда такого не случалось, началось с определенного момента времени на нескольких хостах дома и на работе.

сосед сварку купил

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

Почитай про ganstalking, цель его как раз довести targetted individual до психушки.

не твой одноклассник писал?

Удалил ты 1000 записей через одну. Вот и дырки

Я не доверяю хранилкам, тем более жирным, тем более с батарейкой. Доверяю только ZFS без батарейки на максимально простом железе типа Core2. По крайне мере для критически важных проектных пулов для сорцов, где ненужна высокая производительность как в проде.

Влияет на проектном пуле, да и пуле виртуалок тоже. Еще как влияет, дефрагментация 1-2 раза в год очень ускоряет.

Ну это же временное улучшение и не более. Если так критично - нужно просто закладывать много свободного места (как и для самих ссд, совпадение, да?:) )

Ну это же временное улучшение и не более. Если так критично - нужно просто закладывать много свободного места (как и для самих ссд, совпадение, да?:) )

Так дефрагментация - временное улучшение почти всегда :) Например, чтобы промышленная база Db2 работала с приемлемой скоростью, в отдельных кейсах ее нужно дефрагментировать (REORG) еженочно (если offline) и от файловой системы это не зависит, нужно дефргагментировать даже на блочных устройствах raw DMS (database managed space). Дефргаментацию NTFS тоже обычно делают в период низкой утилизации FS.

Мне кажется, лучше постепенно добавлять свободное место в пул, если есть такая возможность?

Это пока есть ресурс дефрагментацию проводить)

А что же подходит, если мне нужен почти весь функционал ZFS + еще дефрагментация?

btrfs там есть дефрагментация. Но мой опыт показал, что такой адской устойчивости как у zfs у неё нет.

ZFS позволила сохранить данные.

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

Если тормоза на zfs send возможно, нужно оптимизировать настройки zfs. Как именно хранятся данные: в виде файлов на zfs или в виде образов на zvol? Если это файлы, то что это за файлы: какой тип, какой средний размер файла, нет ли среди них обновляемых, типа хранилища mssql? Я намекаю на то, что нужно подобрать размер recordsize в случай с файлами и volblocksize в случае с томами. Ещё нужно попробовать поменять настойку файловой системы logbias. zfs receive не меняет настройки recordsize и volblocksize, т.е. только копированием. Далее, имеет смысл вынести метаданные на отдельные устройства: на хорошие SSD, можно взять БУ на avito intel S3700 и oracle там сейчас есть, относительно не дорогие.

Так можно же автоматизировать send | receive, чтобы не набирать вручную все это.

Очень сомнительное решения. Я так понял там SSD и так-то не айс. Это просто добьёт их. Если есть рерулярный бекап под мониторингом, можно вместо mirror перевести всё в одиночные диски, станет быстрее.

И так Samsung EVO, но согласен, для метаданных можно добавить еще SSD.

Сейчас есть 32, 64 и 128ГБ VNME Optane - они, за счет не большого объема стоят, относительно не дорого. Рекомендую.

На источнике одиночный SSD для данных.

zfs работает лучше, если есть хотя бы 2 диска 😊

Для SLOG еще отдельный старенький SSD на выброс, он же L2ARC для пулов из одиночных HDD.

Очень сомнительное решения. Я так понял там SSD и так-то не айс. Это просто добьёт их. Если есть рерулярный бекап под мониторингом, можно вместо mirror перевести всё в одиночные диски, станет быстрее.

Дефрагментация 1-2 раза в год почти не повлияет на износ, но влияет на экономию моего времени.

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

Дефрагментация 1-2 раза в год почти не повлияет на износ, но влияет на экономию моего времени.

Еще надо стараться не забивать пул более 80%

btrfs там есть дефрагментация. Но мой опыт показал, что такой адской устойчивости как у zfs у неё нет.

Это уж как получается до очередного апгрейда.

Я все же думаю, что проблема именно в самих SSD. Как я писал выше, SSD вначале заполняет память в 1-битовом режиме, потом, по мере расхода ячеек, переводит часть блоков в 3-х битовый, а он очень, очень плохой: в 100 раз мелоеннее запись и ущерб от записи в 10 раз больше и чтение потом тоже деградирует. Я думаю, вы столкнулись именно с эти. Надо просто другие SSD.

Samsung EVO долгое время были общепризнанными лидерами в своей ценовой категории, да и сейчас пока очень популярны. Проблема повторяема, после пересоздания пула скорость чтения растет, а zpool ессно показывает меньшую фрагментацию свободного пространства, зачем эти гадания про trim? Понятно, что если тримнуть. то скорость вероятно записи еще вырастет, но в обоих случаях вырастет примерно одинаково, как на старом пуле, так и на новом. Для HDD кстати абсолютно тоже самое, в нем ведь нет трима? И у меня с ростом фрагментации накапливаются лаги по чтению, а не записи.

Я ничего не писал про трим 😊 я писал про 3-х битовую память. Проблемы с ней решаются несколькими способами: 1) не использовать существенную часть накопителя и использовать тримм, чтобы накопитель поддерживал достаточный объем 1-битовых ячеек. 2) очень быстрый контроллер и объем SSD, тогда проблема маскируется огромным количеством потоков, в котором работает контроллер. Если бы проблема была только во фрагментации, я бы с ней точно столкнулся, а на моих SSD катастрофического падения производительности нет. Даже на жестких дисках нет.

Раз в год - это разумно. Я сам так делаю 😊

Я все же думаю, что проблема именно в самих SSD. Как я писал выше, SSD вначале заполняет память в 1-битовом режиме, потом, по мере расхода ячеек, переводит часть блоков в 3-х битовый, а он очень, очень плохой: в 100 раз мелоеннее запись и ущерб от записи в 10 раз больше и чтение потом тоже деградирует. Я думаю, вы столкнулись именно с эти. Надо просто другие SSD.

Samsung EVO долгое время были общепризнанными лидерами в своей ценовой категории, да и сейчас пока очень популярны. Проблема повторяема, после пересоздания пула скорость чтения растет, а zpool ессно показывает меньшую фрагментацию свободного пространства, зачем эти гадания про trim? Понятно, что если тримнуть. то скорость вероятно записи еще вырастет, но в обоих случаях вырастет примерно одинаково, как на старом пуле, так и на новом. Для HDD кстати абсолютно тоже самое, в нем ведь нет трима? И у меня с ростом фрагментации накапливаются лаги по чтению, а не записи.

Я ничего не писал про трим 😊 я писал про 3-х битовую память. Проблемы с ней решаются несколькими способами: 1) не использовать существенную часть накопителя и использовать тримм, чтобы накопитель поддерживал достаточный объем 1-битовых ячеек. 2) очень быстрый контроллер и объем SSD, тогда проблема маскируется огромным количеством потоков, в котором работает контроллер. Если бы проблема была только во фрагментации, я бы с ней точно столкнулся, а на моих SSD катастрофического падения производительности нет. Даже на жестких дисках нет.

фрагментация дает падение скорости, но старнно что на ссд она прямо таки для тебя ужасная. у тебя случаем atime не включен?

хорошо вам мелкопульным)

Не то, чтобы ужасная, но появляются провалы в скорости чтения. А разве на скорость чтения send влияет atime?

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

Создатели zfs утверждают, что в дефрагментаторе нет нужды, т.к. если пул заполнен не полностью, zfs эффективно и в достаточной мере противодейтвует фрагментации. У вас просто жолжно быть 20% свободного пространства. У меня, в основном на пулах базы данных внутри zvol, снимки каждые несколько часов. Свободное место имеется. Базы данных на intel S3700, intel P3610 и особенно критичные на intel optane (на коньсьюмерском optane :-) ). Для увеличения быстродействия, в zvol я использую volblocksize 16k, ntfs unit 16k и внутри баз данных recordsize 16k. Еслть и пулы с данеыми, там ntfs unit 16k с доками. Так же снимки каждые несколько часов. Раз в год пересодаю пул, на всякий случай. По моему, проблемы с фрагментацией начинаются, когда на пуле остаётся мало места.

смотри, я записал 100 блоков. потом еще 50, перезапизао из тех 100 блоков 25, (ков их запишет в другое место). теперь пишу еще 50. как оно запишет? в новое место скорей всего. а теперь пишу 15. куда? в дырку. и так оно будет тасовать до тех пор, пока из всего этого не наделает дырок. такой алгоритм наверняка во всех приличных система, за исключением одного: там эта фигня случается только при удалил/записал. а тут при каждой записи

в новое место скорей всего ЕМНИП всегда в новое

Создатели zfs утверждают, что в дефрагментаторе нет нужды, т.к. если пул заполнен не полностью, zfs эффективно и в достаточной мере противодейтвует фрагментации. У вас просто жолжно быть 20% свободного пространства. У меня, в основном на пулах базы данных внутри zvol, снимки каждые несколько часов. Свободное место имеется. Базы данных на intel S3700, intel P3610 и особенно критичные на intel optane (на коньсьюмерском optane :-) ). Для увеличения быстродействия, в zvol я использую volblocksize 16k, ntfs unit 16k и внутри баз данных recordsize 16k. Еслть и пулы с данеыми, там ntfs unit 16k с доками. Так же снимки каждые несколько часов. Раз в год пересодаю пул, на всякий случай. По моему, проблемы с фрагментацией начинаются, когда на пуле остаётся мало места.

кстати, куда делись люди, у которых зфс самая быстра....

Не передергивай, я говорил что в определённых кейсах, а не во всех

я даже знаю в каких. sync=disabled )

кстати, куда делись люди, у которых зфс самая быстра....

кстати, куда делись люди, у которых зфс самая быстра....

С быстрым и огромным L2ARC в режиме полного кеширования и быстрым SLOG, почему бы ей не быть самой быстрой и в то же время самой надежной, но это дорогое оборудование с промышленными SSD, большой рамой, быстрым процом и шинами.

С быстрым и огромным L2ARC в режиме полного кеширования и быстрым SLOG, почему бы ей не быть самой быстрой и в то же время самой надежной, но это дорогое оборудование с промышленными SSD, большой рамой, быстрым процом и шинами.

потому что остальные тоже будут быстрее на этом железе

Но не будут одновременно такими же надежными.

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

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