Станислав
Где - на них ? 100 процентных гарантий никакой рейд не дает, вы же в курсе да ?
Если убрать гонор, то сможете понять, что я ответил на сообщение про древние б/у диски по 500гб, которые обсуждались. А когда включите голову, а только хамство, то поймёте, возможно, почему.
Georg🎞️🎥
Если убрать гонор, то сможете понять, что я ответил на сообщение про древние б/у диски по 500гб, которые обсуждались. А когда включите голову, а только хамство, то поймёте, возможно, почему.
Я про 500гиговые диски ничего не знаю , это не мой кейс , и я по ним ничего не предлагал. Про «включить голову» - это тоже как бы хамство и в реальной жизни вы сидите на жопе с разбитым носом, умники 🤝 Гонора никакого не было , а вот интернет герои задолбали
Станислав
Кто-то тебя обидел недавно? Я лишь ответил взаимностью на твое хамство. Можешь продолжить вести себя так, заслужи больше доверия
exit_node🙂‍↕️
Georg🎞️🎥
Кто-то тебя обидел недавно? Я лишь ответил взаимностью на твое хамство. Можешь продолжить вести себя так, заслужи больше доверия
Тыкать будешь жене под одеялом. Есть что сказать - в личку , я тебе дам тел , можешь высказаться , но ты зассышь :))) Вдруг я тебя тоже обижу ))
Vladislav
но выйти из строя они могут слегка иначе, чем просто умереть, самый простой пример Диск *уснул* и пока он будет разгоняться система посчитает, что он выпал и убьёт его по timeout
Georg🎞️🎥
Непропорциональный ответ разбивать нос за такую фразу 😁
Ну это как и кому сказать , обычно в реале мне не хамят 🤔 А так я не сторонник подобных мер
Fedor
Неделю ридонли за нарушение общих правил
Fedor
Так может потому, что в реале ты не хамишь? Ссышь...
в чате переход на личности не приветствуется
Станислав
в чате переход на личности не приветствуется
Выше прочтите переписку. Не я хамить стал
Fedor
Выше прочтите переписку. Не я хамить стал
Здесь - техническое сообщество. Если хочется поддержать разговор на темы, не относящиеся к технике - создан канал флуда.
Andrey
народ как подключить 2 диска в zfs если на них было зеркало zfs диски перенёс с другого сервера. т. е. системный диск на ssd zfs, и к нему да ещё обычных но в зеркале с данными.
Andrey
я же правельно понимаю zfs import - f
Ivan
я же правельно понимаю zfs import - f
зависит от того по каким путям нужно смонтировать пул
Andrey
раньше он у меня был в /dpool
Andrey
в корне
Andrey
видно что пул видит но смонтировать его как на по стоянку
Andrey
pool: dpool id: 5886224408572262990 state: ONLINE status: The pool was last accessed by another system. action: The pool can be imported using its name or numeric identifier and the '-f' flag. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-EY config: dpool ONLINE mirror-0 ONLINE ata-WDC_WD30EZRX-00DC0B0_WD-WMC1T1985256 ONLINE ata-WDC_WD30EZRX-00DC0B0_WD-WMC1T1662988 ONLINE
Andrey
как его понять ссылается на статью где надо -f применить, применил
Andrey
NAME USED AVAIL REFER MOUNTPOINT rpool 17.7G 440G 104K /rpool rpool/ROOT 2.97G 440G 96K /rpool/ROOT rpool/ROOT/pve-1 2.97G 440G 2.97G / rpool/data 9.80G 440G 96K /rpool/data rpool/data/vm-100-disk-0 92K 440G 92K - rpool/data/vm-100-disk-1 9.80G 440G 9.80G - rpool/data/vm-100-disk-2 64K 440G 64K - rpool/var-lib-vz 4.88G 440G 4.88G /var/lib/vz
Andrey
zpool status pool: rpool state: ONLINE config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 nvme-eui.0026b7683d0d7be5-part3 ONLINE 0 0 0 errors: No known data errors
Sergey
указать имя пула явно: import -f dpool
Andrey
указать имя пула явно: import -f dpool
вот запарился и как то не дописал 🫠
Andrey
Все получилось
Александр
Всем Привет! Кто-нибудь сталкивался с такой проблемой? Я использую 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 ), контрольные суммы не сойдутся ( частично в файле вместо данных будут лежать нули ) Не подскажете есть ли какой-то способ это поправить?
Vladislav
Всем Привет! Кто-нибудь сталкивался с такой проблемой? Я использую 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 ), контрольные суммы не сойдутся ( частично в файле вместо данных будут лежать нули ) Не подскажете есть ли какой-то способ это поправить?
Вопрос звучит примерно как "Я вытаскиваю подмонтированный диск из сервера, получаю сотни ошибок I/O, а когда возвращаю запись, которая ушла в I/O timeout отсутствует на диске." Ответ: Не надо вытаскивать диск
Vladislav
Можно сделать запись с проверкой записанного, условно rsync --append-verify
Александр
Можно сделать запись с проверкой записанного, условно rsync --append-verify
спасибо, сейчас попробую, я просто сделал аналогичный тест с lvm и контрольные суммы сошлись. и Видимо пошёл не по тому пути
Vladislav
Другой вопрос, что ZFS помещает данные в буфер перед сбросом на диск поэтому DD уверен, что он их записал, а в реальности нет, поэтому рекомендую повторить тест с dd flag=sync
sexst
А мне теперь стало любопытно почему lvm не ломается
Vladislav
А мне теперь стало любопытно почему lvm не ломается
Потому что LVM не держит данные в буфере
Andrey
а синхронизацию своего пула случайно не отключали типа для быстро действия, очень похоже что отключена, насколько известно, zfs считает записаные данные когда сверит что записано, только после этого продолжает дальше в случае отключения синхронизации за 5 сек в лёгкую потерять данные. Если я конечно не ошибаюсь.
sexst
Потому что LVM не держит данные в буфере
А, всё. Я сначала затупил не понял где zfs крутится. Это не хост с zfs ребутнули, а диски из-под него выдернули
sexst
Причина почему sync важен как раз в этом
dd без синка почти всегда гонять в принципе незачем. А без status=progress ещё и непонятно чо там у него творится
Dexex
dd без синка почти всегда гонять в принципе незачем. А без status=progress ещё и непонятно чо там у него творится
Лолэ. Впервые слышу. Сколько хардов и всякой шляпы я копировал так с 2002 года.
sexst
Лолэ. Впервые слышу. Сколько хардов и всякой шляпы я копировал так с 2002 года.
Ну вот теперь вы услышали что вместо dd <blah blah blah> && sync (для уверенности) можно просто flag=sync написать, да.
Dexex
То что zfs асинхронная и не гарантирована у нее запись это не означает что там с софтиной что то не так. С ext4 такое наблюдалось - отложенная запись
sexst
Не относится к кейсам когда вы биты из файла в файл копируете на отвали
Александр
А, всё. Я сначала затупил не понял где zfs крутится. Это не хост с zfs ребутнули, а диски из-под него выдернули
ну вообще я ребутал хост с зфс, я по FC раздавал блочное устройство на нём создал ext4 и писал файлик.
Vladislav
А, всё. Я сначала затупил не понял где zfs крутится. Это не хост с zfs ребутнули, а диски из-под него выдернули
А без разницы, у тебя ZFS если выдернуть питание во время активной записи без использования sync сообщит системе выше (в данном случае другому серверу) что всё записано. Система на этом другом сервере (dd в данном случае) соответственно не станет повторять запись ибо получила что данные записаны. Просто обычно 5секунд записи не настолько критичны для 99% систем, а там где критично данные идут с флагом синк
Александр
Лучше на пуле включи sync=always
Я кстати включал, и вроде это не сработало, но я дд без флага sync использовал. Возможно надо и там и там включить)
Vladislav
Мне кажется он не применился
Free
Странная арифметика суммирования 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
Dexex
Странная арифметика суммирования 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. То есть вообще ни одной операции не сделать. Пришлось пул убить.
Fedor
Странная арифметика суммирования 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
можно попробовать посмотреть тут - вдруг что-то такое есть. если нет - в идеале на чистом пуле воспроизвести эту ситуацию и создать новый issue.
Fedor
может, на меньших масштабах данных такое тоже получится воспроизвести
Free
там есть нюансы с размером снапов, они относительны к следующему снапу а не к абсолютному размеру снапа.
Да, интересно было бы еще посмотреть размеры после удаления одного из снапов. Но суммарно два снапа должны были бы как раз все изменения учесть?
George
Да, интересно было бы еще посмотреть размеры после удаления одного из снапов. Но суммарно два снапа должны были бы как раз все изменения учесть?
Гадать смысла нет, стоит цифры до после удаления каждого снапа смотреть. https://github.com/openzfs/zfs/issues/13414 https://github.com/mafm/zfs-snapshot-disk-usage-matrix
Andrey
народ подскажите как правельно определить на каком из ssd зеркало и какой из них основной диск, есть 4 SSD, 1 чистый, 2 бало сделано miror, а вот 3й не пой му откуда взялся хочу удалить, но не понимаю, кто есть кто
Alexey
Уважайте, пожалуйста, людей, пишите грамотнее... zpool status -v Покажет Вам все диски во всех пулах в каталоге ls -l /dev/disk/by-id найдите соответствия с ссылками в системе (ls -l /dev/sd*) и серийниками. Потом посмотрите на наклейки на ssd и сопоставьте серийники.
Andrey
Уважайте, пожалуйста, людей, пишите грамотнее... zpool status -v Покажет Вам все диски во всех пулах в каталоге ls -l /dev/disk/by-id найдите соответствия с ссылками в системе (ls -l /dev/sd*) и серийниками. Потом посмотрите на наклейки на ssd и сопоставьте серийники.
zpool status -v pool: rpool state: ONLINE scan: scrub repaired 0B in 00:04:36 with 0 errors on Sun Jun 8 00:28:37 2025 config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvme-eui.00253853319201a1-part3 ONLINE 0 0 0 nvme-eui.00253853319201a3-part3 ONLINE 0 0 0 errors: No known data errors
Alexey
у Вас nvme ssd, значит смотрите и сопоставляйте серийники из /dev/nvme* и /dev/disk/by-id/
Alexey
вот мой пример из каталого /dev/disk/by-id: nvme-WDS500G3X0C-00SJG0_211174800244 -> ../../nvme0n1
Alexey
видно серийник
Andrey
Alexey
вопрос не понял
Александр
Спасибо я как раз не мог понять как найти этот eui
Еще можно смотреть udevadm info /dev/<your_device> Тоже много полезной инфы можно увидеть
Andrey
Вот есть ssd на zfs скрин сегодня делал
Andrey
Это вчерашний скрин, data unit write увеличился силно