Так а толку от того, что ФС цела, если данных не осталось из 300Гб?

Я очень долгое время работаю с zfs и что я только не делал, и с одиночными накопителями и с zfs поверх zvol и с ecc и без ecc и даже на углюченных компьютерах. И по результатам моего опыта вся ваша история выглядит очень сомнительно. Скорее я поверю в вашу ошибку: zfs создали на одном устройстве, а ищете на другом или сами де перезаписали fs на устройстве после или во время записи данных.

Я очень долгое время работаю с zfs и что я только не делал, и с одиночными накопителями и с zfs поверх zvol и с ecc и без ecc и даже на углюченных компьютерах. И по результатам моего опыта вся ваша история выглядит очень сомнительно. Скорее я поверю в вашу ошибку: zfs создали на одном устройстве, а ищете на другом или сами де перезаписали fs на устройстве после или во время записи данных.

Я очень долгое время работаю с zfs и что я только не делал, и с одиночными накопителями и с zfs поверх zvol и с ecc и без ecc и даже на углюченных компьютерах. И по результатам моего опыта вся ваша история выглядит очень сомнительно. Скорее я поверю в вашу ошибку: zfs создали на одном устройстве, а ищете на другом или сами де перезаписали fs на устройстве после или во время записи данных.

Если это про мою "пропажу" пула - то ваше предположение не верно. Я ведь писал, чем закончилось: импорт с ключами -FX позволил "найти" и восстановить пул

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

Вам надо знать, что подобный импорт может сделать пул нестабильным. Лучше всего скопировать с него данные, а пул пересоздать. Если данные не копируются через zfs send -R ... | zfs receive ... По причине ошибок чтения или ошибок контрольных сумм, то можно временно разрешить пересылать поврежденные даныые через установку параметра модуля zfs. Это можно сделать "на лету". У меня есть ещё идея, что могло произойти. zfs разработана для работы с серверными накопителями. Их особенностью является то, что они никогда не создают ситуацию с timeout операций чтения и записи. Например, встречая нечитаемые данные, накопитель просто сообщает об ошибке чтения. У вас мог быть накопитель с типом записи smr а не cmr. Smr-накопители могут надолго - десятки минут уходить в астрал, накопив большое количество данных для записи во внутреннем буфере. Потенциально это может вызвать недозапись несколтких ГБ данных. SMR-накопители - это обсалютное зло, их нельзя использовать в zfs, а по моему мнению вообще нигде. Производители стараются скрыть факт использования технологии smr. При потерях данных, они говорят, что дескать их накопители расчитаны только на бытовые нагрузки, хотя непрерывное заполнение накопителя данными и есть бытовая нагрузка. Тем не менее, производители считают что при потере данных smr-дисксми по причине их зависания при интенсивной продолжительной записи допустимо, а для кого не допустимо, мол пусть серверные покупают. Позиция, на мой взгляд, конченых ублюдков.

Там exos x18

Тогда остаётся какая-то чертовщина

Посмотрите выше на ещё одно предположение. Таких гепредскащуемвх ошибок на роаном месте за всю историю эксплуатации zfs я не встречал. А эксплуатирую я zfs активно и на серверах и на десктопах

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

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

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

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

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

Это вопрос времени. Как диски устанут, так и развалится. Хотя раскажет при пеовых же ошибках, если у вас настроен мониторинг. Так что ситуация это точно не редкая, искать не надо. Тут надо сделать оговорку, что развалится значит будут ошибки чтения. Так чтоб напроч убилась, надо чтобы рейд глючил. Но вот в этом случае тоже запросто. У меня было так с глючашим hba, перегревался и диски зависали. Zfs продержался несколько лет на нем с переодическими перезагрузками, но однажды не примонтировался. Сильно не упорствовали, восстановили с бекапа.

Прошу прощение за опечатки. Со смартфона нет сил исправлять.

есть твои данные, zfs далает вид, что умная, и копирует самые юзабельные данные в arc (оперативную память) когда arc кончается, то самые неюзабельные в нём данные перемещаются из arc в l2arc

Вы понимаете, с аппаратным рейдом я неоднократно сталкивался, например с такой проблемой: диск один или оба в зеркале отлают кривые данные - не то что на них записано и рейд это не видит, накапливаются silent corruption в файлах пока не падает фс или база данных какая-нибудь. К этому моменты во всех бекапах уже давно кривые данные. И вы даже не узнаете об этой ситуации. Zfs в этой же ситуации, но не поверх аппаратного рейда, вас во первых предупредит, во вторых, в 99.9% случаев позволит вытащить данные с двух поврежденных дисков. Ошибку чтения допустит только при наличие ошибок на обоих дисков по одинаковым lba-адресам. Но и в этом случае, во первых таких ошибок будет в десятки тысяч раз меньше чем количество ошибок на дисках, во вторых, их будет видно, а в случае zfs fs (а не zvol) вы увидите в каком файле повреждения, а какие файлы целые. Короче, несмотря на ваше заявление, размещать zfs поверх рейда контрпролуктивно

есть люди, которые гвозди в розетку совали и выжили

никто и не отрицал

Ну не скажи, @Riv1329 вполне не согласен с тем, что не ECC память могла сломать массив

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

а вот по refs чатиков нет, там всё норм

если у вас серверная винда находит обновы и сама ребуится - вы что-то делаете не так

/report

/report

Как думаете, что это может означать? Подменный диск абсолютно новый.

проблемы с кабелем/портом/питанием

Но тогда по идее бы и все аналогичные диски выдали бы ошибку, те что подключены по этому кабелю. У меня в серваке бэкплейн и там 3 кабеля SFF идут от бэкплейна на HBA

3 кабеля, в каждом по 4 линии, ну

Ребята, подскажите. Столкнулся с такой проблемой. Ночной еженедельный скраб показал на одном из дисков много ошибок и отметил его как faulted. Я поставил вместо него новый, абсолютно новый диск, но сразу по ходу ресилверинга полезли ошибки записи в zpool status.

вообще конфигурация так себе... йопсов всего в 6 раз больше а рика много если нет бэкапов

Бэкапы есть. Но если честно не могу представить конфу более оптимальную по соотношению иопсам и риску

ну если надо на весь объем то да .. а так я сделал всё мелкое на спешл вдев... + л2арк

Руки пока не дошли

Ааа, понял! Спасибо. Пойду поменяю для начала ))

Как же грустно, когда вроде книжки читал, а базовых вещей так и не узнал

А нахер пойти не хотите?

А зачем мне к Вам?

Бэкапы есть. Но если честно не могу представить конфу более оптимальную по соотношению иопсам и риску

А нахер пойти не хотите?

Боюсь вы адрессом ошиблись.

А как считали риски? По какой формуле? Вероятность выхода из строя диска как высчитывали? А время на износ считали? А память ecc используете? А аварию симулировали?

Как же грустно, когда вроде книжки читал, а базовых вещей так и не узнал

Я уже сказал, и направил вас в нужном направлении. Не вижу смысла в общении с вами конкретно. От ваших советов толку никогда не было. По сему не вижу смысла.

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

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

Ни описания стенда Ни сервера Ни какая память Ни модель дисков Ни какой hba

Только у этого индивида их нет

не надо так, с оскорблениями чат лучше не становится.

не надо так, с оскорблениями чат лучше не становится.