Где - на них ? 100 процентных гарантий никакой рейд не дает, вы же в курсе да ?

Миллионы мелких файлов 1m поставили

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

Я про 500гиговые диски ничего не знаю , это не мой кейс , и я по ним ничего не предлагал. Про «включить голову» - это тоже как бы хамство и в реальной жизни вы сидите на жопе с разбитым носом, умники 🤝 Гонора никакого не было , а вот интернет герои задолбали

Я про 500гиговые диски ничего не знаю , это не мой кейс , и я по ним ничего не предлагал. Про «включить голову» - это тоже как бы хамство и в реальной жизни вы сидите на жопе с разбитым носом, умники 🤝 Гонора никакого не было , а вот интернет герои задолбали

Смертельнее в этой схеме скорее тот факт, что это 500ГБ 2.5'' и потенциально ноутбочные WD Blue какой-нибудь

Чем плохо? Быстро выходят из строя и рейд не успеет пересобраться?

Кто-то тебя обидел недавно? Я лишь ответил взаимностью на твое хамство. Можешь продолжить вести себя так, заслужи больше доверия

Я про 500гиговые диски ничего не знаю , это не мой кейс , и я по ним ничего не предлагал. Про «включить голову» - это тоже как бы хамство и в реальной жизни вы сидите на жопе с разбитым носом, умники 🤝 Гонора никакого не было , а вот интернет герои задолбали

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

Непропорциональный ответ разбивать нос за такую фразу 😁

Непропорциональный ответ разбивать нос за такую фразу 😁

Ну это как и кому сказать , обычно в реале мне не хамят 🤔 А так я не сторонник подобных мер

Так может потому, что в реале ты не хамишь? Ссышь...

в чате переход на личности не приветствуется

Выше прочтите переписку. Не я хамить стал

я же правельно понимаю zfs import - f

указать имя пула явно: import -f dpool

Всем Привет! Кто-нибудь сталкивался с такой проблемой? Я использую Ubuntu 20.04 LTS с ZFS 2.1.12 ( так же тестировал на 2.2.4 и на 2.3.1 ). На этой системе есть zpool raid1 и zvol на 700 гигабайт. Подключаю через FC к убунте. Генерю рандомный бинарный файлик командой dd if=/dev/urandom of=dd.bin bs=1G count=150 Если во время передачи файла размером 150 гигабайт dd if=/mnt/sdb/dd.bin of=/mnt/FC/dd.bin status=progress Отправляем сервер в ребут и после его поднятия dd продолжает записывать файл. Когда файл полностью скопируется, я считаю его контрольную сумму и проверяю с исходной ( через sha512 ), контрольные суммы не сойдутся ( частично в файле вместо данных будут лежать нули ) Не подскажете есть ли какой-то способ это поправить?

Всем Привет! Кто-нибудь сталкивался с такой проблемой? Я использую Ubuntu 20.04 LTS с ZFS 2.1.12 ( так же тестировал на 2.2.4 и на 2.3.1 ). На этой системе есть zpool raid1 и zvol на 700 гигабайт. Подключаю через FC к убунте. Генерю рандомный бинарный файлик командой dd if=/dev/urandom of=dd.bin bs=1G count=150 Если во время передачи файла размером 150 гигабайт dd if=/mnt/sdb/dd.bin of=/mnt/FC/dd.bin status=progress Отправляем сервер в ребут и после его поднятия dd продолжает записывать файл. Когда файл полностью скопируется, я считаю его контрольную сумму и проверяю с исходной ( через sha512 ), контрольные суммы не сойдутся ( частично в файле вместо данных будут лежать нули ) Не подскажете есть ли какой-то способ это поправить?

Можно сделать запись с проверкой записанного, условно rsync --append-verify

А мне теперь стало любопытно почему lvm не ломается

Другой вопрос, что ZFS помещает данные в буфер перед сбросом на диск поэтому DD уверен, что он их записал, а в реальности нет, поэтому рекомендую повторить тест с dd flag=sync

а синхронизацию своего пула случайно не отключали типа для быстро действия, очень похоже что отключена, насколько известно, zfs считает записаные данные когда сверит что записано, только после этого продолжает дальше в случае отключения синхронизации за 5 сек в лёгкую потерять данные. Если я конечно не ошибаюсь.

Потому что LVM не держит данные в буфере

Причина почему sync важен как раз в этом

dd без синка почти всегда гонять в принципе незачем. А без status=progress ещё и непонятно чо там у него творится

Лолэ. Впервые слышу. Сколько хардов и всякой шляпы я копировал так с 2002 года.

А, всё. Я сначала затупил не понял где zfs крутится. Это не хост с zfs ребутнули, а диски из-под него выдернули

А, всё. Я сначала затупил не понял где zfs крутится. Это не хост с zfs ребутнули, а диски из-под него выдернули

А без разницы, у тебя ZFS если выдернуть питание во время активной записи без использования sync сообщит системе выше (в данном случае другому серверу) что всё записано. Система на этом другом сервере (dd в данном случае) соответственно не станет повторять запись ибо получила что данные записаны. Просто обычно 5секунд записи не настолько критичны для 99% систем, а там где критично данные идут с флагом синк

я проверил с rsync и на самом деле коррапта не было) Спасибо.

А без разницы, у тебя ZFS если выдернуть питание во время активной записи без использования sync сообщит системе выше (в данном случае другому серверу) что всё записано. Система на этом другом сервере (dd в данном случае) соответственно не станет повторять запись ибо получила что данные записаны. Просто обычно 5секунд записи не настолько критичны для 99% систем, а там где критично данные идут с флагом синк

Я ещё нашёл zfs_vdev_async_write_max_active решил выставить значение в 0. Как я понял зфс перестанет делать асинхронные записи, попробую поиграться с этим сегодня)

Я ещё нашёл zfs_vdev_async_write_max_active решил выставить значение в 0. Как я понял зфс перестанет делать асинхронные записи, попробую поиграться с этим сегодня)

Лучше на пуле включи sync=always

А без разницы, у тебя ZFS если выдернуть питание во время активной записи без использования sync сообщит системе выше (в данном случае другому серверу) что всё записано. Система на этом другом сервере (dd в данном случае) соответственно не станет повторять запись ибо получила что данные записаны. Просто обычно 5секунд записи не настолько критичны для 99% систем, а там где критично данные идут с флагом синк

Странная арифметика суммирования USED в датасете. Неожиданно упало до нуля свободное место на пуле. Рост данных не мог быть таким большим, чтобы всё исчерпать. Удалил 2 снапшота не очень большого размера - и место вдруг увеличилось во много раз больше, чем было в снапшотах. К сожалению, не документировал эти изменения, но решил повторить на другом подобном пуле (там до нуля место не исчерпалось, но ситуация похожая) Со снапшотами: root@S08 ~# zfs list NAME USED AVAIL REFER MOUNTPOINT t4.5s 3.21T 309G 96K /t4.5s t4.5s/330 3.21T 309G 1.90T /t4.5s/330 t4.5s/330@send0 75.3G - 2.14T - t4.5s/330@send1 16.3G - 2.09T - Удаляю снапшоты (общим размером менее 100G) - прибавка целый терабайт! NAME USED AVAIL REFER MOUNTPOINT t4.5s 2.19T 1.33T 96K /t4.5s t4.5s/330 1.90T 1.33T 1.90T /t4.5s/330 PS Debian 6.1.0-32-amd64 root@S08 ~# zfs version zfs-2.1.11-1+deb12u1 zfs-kmod-2.1.11-1+deb12u1

Только недавно разбирали похожую ситуацию. Удалил снапшоты и место тупо 0. То есть вообще ни одной операции не сделать. Пришлось пул убить.

Странная арифметика суммирования USED в датасете. Неожиданно упало до нуля свободное место на пуле. Рост данных не мог быть таким большим, чтобы всё исчерпать. Удалил 2 снапшота не очень большого размера - и место вдруг увеличилось во много раз больше, чем было в снапшотах. К сожалению, не документировал эти изменения, но решил повторить на другом подобном пуле (там до нуля место не исчерпалось, но ситуация похожая) Со снапшотами: root@S08 ~# zfs list NAME USED AVAIL REFER MOUNTPOINT t4.5s 3.21T 309G 96K /t4.5s t4.5s/330 3.21T 309G 1.90T /t4.5s/330 t4.5s/330@send0 75.3G - 2.14T - t4.5s/330@send1 16.3G - 2.09T - Удаляю снапшоты (общим размером менее 100G) - прибавка целый терабайт! NAME USED AVAIL REFER MOUNTPOINT t4.5s 2.19T 1.33T 96K /t4.5s t4.5s/330 1.90T 1.33T 1.90T /t4.5s/330 PS Debian 6.1.0-32-amd64 root@S08 ~# zfs version zfs-2.1.11-1+deb12u1 zfs-kmod-2.1.11-1+deb12u1

Странная арифметика суммирования USED в датасете. Неожиданно упало до нуля свободное место на пуле. Рост данных не мог быть таким большим, чтобы всё исчерпать. Удалил 2 снапшота не очень большого размера - и место вдруг увеличилось во много раз больше, чем было в снапшотах. К сожалению, не документировал эти изменения, но решил повторить на другом подобном пуле (там до нуля место не исчерпалось, но ситуация похожая) Со снапшотами: root@S08 ~# zfs list NAME USED AVAIL REFER MOUNTPOINT t4.5s 3.21T 309G 96K /t4.5s t4.5s/330 3.21T 309G 1.90T /t4.5s/330 t4.5s/330@send0 75.3G - 2.14T - t4.5s/330@send1 16.3G - 2.09T - Удаляю снапшоты (общим размером менее 100G) - прибавка целый терабайт! NAME USED AVAIL REFER MOUNTPOINT t4.5s 2.19T 1.33T 96K /t4.5s t4.5s/330 1.90T 1.33T 1.90T /t4.5s/330 PS Debian 6.1.0-32-amd64 root@S08 ~# zfs version zfs-2.1.11-1+deb12u1 zfs-kmod-2.1.11-1+deb12u1

Странная арифметика суммирования USED в датасете. Неожиданно упало до нуля свободное место на пуле. Рост данных не мог быть таким большим, чтобы всё исчерпать. Удалил 2 снапшота не очень большого размера - и место вдруг увеличилось во много раз больше, чем было в снапшотах. К сожалению, не документировал эти изменения, но решил повторить на другом подобном пуле (там до нуля место не исчерпалось, но ситуация похожая) Со снапшотами: root@S08 ~# zfs list NAME USED AVAIL REFER MOUNTPOINT t4.5s 3.21T 309G 96K /t4.5s t4.5s/330 3.21T 309G 1.90T /t4.5s/330 t4.5s/330@send0 75.3G - 2.14T - t4.5s/330@send1 16.3G - 2.09T - Удаляю снапшоты (общим размером менее 100G) - прибавка целый терабайт! NAME USED AVAIL REFER MOUNTPOINT t4.5s 2.19T 1.33T 96K /t4.5s t4.5s/330 1.90T 1.33T 1.90T /t4.5s/330 PS Debian 6.1.0-32-amd64 root@S08 ~# zfs version zfs-2.1.11-1+deb12u1 zfs-kmod-2.1.11-1+deb12u1

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

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

Уважайте, пожалуйста, людей, пишите грамотнее... zpool status -v Покажет Вам все диски во всех пулах в каталоге ls -l /dev/disk/by-id найдите соответствия с ссылками в системе (ls -l /dev/sd*) и серийниками. Потом посмотрите на наклейки на ssd и сопоставьте серийники.

у Вас nvme ssd, значит смотрите и сопоставляйте серийники из /dev/nvme* и /dev/disk/by-id/

Уважайте, пожалуйста, людей, пишите грамотнее... zpool status -v Покажет Вам все диски во всех пулах в каталоге ls -l /dev/disk/by-id найдите соответствия с ссылками в системе (ls -l /dev/sd*) и серийниками. Потом посмотрите на наклейки на ssd и сопоставьте серийники.

Спасибо я как раз не мог понять как найти этот eui