Возможно, у вас диски потребительского уровня. Когда вы скачиваете данные на том же сервере, чтение и запись идут на один и тот же диск. Возможно, он перегружен и врет о завершении. Может быть, где-то по пути ещё включено кэширование. Просто предположение. IMHO, это вряд ли связано с SMB/VM или ОС/wget. Скорее всего, проблема с диском. Можно провести контролируемый тест, подключив к node1 другой диск и скачав ISO с disk1 на disk2. Или, если достаточно оперативной памяти, создать дисковую подсистему в оперативной памяти для временного хранения. Опять же, просто предположение. Удачи, Blockbridge! Ультра низкая задержка, всё на NVME, общий диск для Proxmox - https://www.blockbridge.com/proxmox

Несколько моментов:
- Описание проблемы "коррупция" довольно расплывчатое. Мне не обязательно знать каждую деталь, но было бы неплохо понять, что именно вы имеете в виду под этим словом.
- Похожих отчетов, как ваш, нет, поэтому, скорее всего, проблема ограничивается вашей средой. Причины могут варьироваться от плохого диска до проблем с памятью, материнской платой или чем-то совершенно другим.
- Поскольку проблема локализована в вашей конкретной среде (используете потребительское оборудование), вам придется попотеть, чтобы сузить круг подозреваемых.
- Вы можете сообщить о проблеме на bugzilla.proxmox.com. Однако без надежной процедуры воспроизведения и отсутствием права на поддержку, эта проблема вряд ли привлечет много внимания.
- Если бы я был на вашем месте и очень хотел бы найти причину, я бы сделал следующее:
a) использовать fio для создания файлов разных размеров (100 м/200 м/500 м/1 г/и т.д.) с предсказуемым шаблоном. Попробуйте определить, в какой момент происходит "коррупция".
b) запустить tcpdump на обеих сторонах, чтобы определить, поступают ли целевые данные в хорошем состоянии и изменяются ли они при записи или уже изменяются при отправке.
c) использовать другие протоколы (ftp, nfs, ssh), чтобы определить, есть ли общие черты в поведении.
d) использовать fio для выполнения обширных операций чтения/записи/проверки на гипервизоре, в виртуальной машине и между ними.
Удачи. Blockbridge: ультранизкозадержечное общее хранилище на базе NVMe для Proxmox - https://www.blockbridge.com/proxmox

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

Почти все ISO файлы, если они не слишком маленькие (т.е. <100M). По второму пункту я тоже чешу репу. Файл не поврежден в источнике. В данном случае на моём 3-м мини ПК я скачал TrueNas Core, который требует ввода sha256sum в PVE download UI для проверки после скачивания. Проверка проходит! И все же результирующий файл поврежден: 1. Установка TrueNas core из ISO в SMB share жалуется на повреждение файла. 2. Если я захожу в samba сервер и делаю sha256sum локально, то он не совпадает. Неудивительно, что установка не удается. Я даже намеренно изменил sha256sum на странице PVE downloader, чтобы убедиться, что он действительно проверяет. Да. Он ловит, что контрольная сумма не совпадает. Не могу представить себе сценарий, где встроенный скачиватель PVE проходит проверку контрольной суммы, а фактический файл на диске – нет. Если только Samba сервер или samba клиент не кэшируют данные и отправляют скачивателю что-то отличное от того, что есть на диске? Я также тестировал копирование ISO из samba share на Windows машину. Эта копия никогда не повреждается. Надеюсь на это, потому что я использую этот samba сервер/vm уже 6-7 лет с большим количеством личных данных. Было бы ужасно, если бы повреждения происходили часто.

Да. Только вот я протестировал Samba-сервер, используя RAM-диск в качестве хранилища (/tmp/isoRepo), и он тоже испортился. Начинаю подозревать, что виноват что-то в Samba-клиенте PVE. Samba-клиент монтирует Samba-шару через добавление SMB в меню PVE/Storage. Это объясняет, почему встроенный скачиватель проходит проверку контрольной суммы, а файл на диске при этом оказывается поврежденным. Я проверил версию wget в PVE, она актуальна и соответствует версии wget, которую я использую в других тестах (wget в VM на Samba-шару).

Эти три машины: 1. zotac ID81 mini PC 2. Mac Mini (2009 года) 3. Beelink SER5 5560U (новая машина). У всех одинаковая версия PVE (последняя), никаких специальных настроек не применялось. Предполагаю, вы хотите узнать марки и модели сетевых карт? Стоит добавить ещё одну деталь (я отредактировал последний пост, чтобы её включить): изначально я сообщал, что повреждения происходят только в том случае, если PVE-хост скачивает файлы в samba-шару с ВМ, размещённой на том же PVE-хосте. Если скачивание происходит из другой ВМ на том же хосте или с другого хоста, повреждений не происходит. Замедление скорости скачивания (опция wget) также не предотвращало повреждений. Это больше не так. Теперь я могу получить повреждения, если samba-ВМ находится на машине #3 (она в 30 раз быстрее, чем 1 или 2), а скачивание идёт с другого PVE-хоста (wget или встроенная функция скачивания ISO в веб-интерфейсе). Похоже, что это связано с тем, что samba-ВМ стала намного быстрее. В итоге, похоже, что повреждения происходят, если клиент скачивания находится на PVE-хосте (wget в командной строке хоста или встроенная функция скачивания ISO в веб-интерфейсе), а целевой адрес — samba-шара. Я не пробовал NFS или SSHFS. Возможно, попробую, но сомневаюсь, что это поможет. Как я уже говорил, samba-ВМ (ubuntu 16) без проблем переносила огромные объёмы личных данных в течение 7 лет. Новая samba-ВМ (свежеустановленный ubuntu 22.04LTS с минимальной конфигурацией samba) также страдает от проблемы с повреждениями. Общий знаменатель, похоже, — wget на PVE-хосте. Aria2c на PVE-хосте не повреждает скачивание, при прочих равных с тестами, вызывающими повреждение wget. Я проведу некоторые эксперименты с SSHFS.

Вот перевод сообщения на русский язык:

Вот моя ситуация: у меня Proxmox работает на двух машинах, назовем их "H" и "D", где H — домашний сервер, а D — настольный компьютер с поддержкой нескольких рабочих мест. - H запускает VM TrueNAS, назовем ее "VMhNAS". - D запускает мою Linux VM (с передачей GPU) и Windows VM (снова с передачей GPU, там две GPU). Теперь, D монтирует хранилище SMB/CIFS с VMhNAS, которая работает на H. У меня там ISO для различных дистрибутивов Linux. Я нашел огромный ISO размером 6 ГБ для тестирования: образ Qube OS. Когда я пытаюсь скачать новый ISO-образ из интерфейса Proxmox на D и выбрать хранилище на VMhNAS, файл становится поврежденным. Скачивание из интерфейса: контрольная сумма просто не проходит. В этом случае D скачивает из интернета, затем передает данные на VMhNAS, которая работает на H. Чтобы понять, откуда берется повреждение, я разбил процесс на части: Во-первых, я скачал прямо на VMhNAS, войдя в TrueNAS. Здесь VMhNAS работает на H, скачивая из интернета и сохраняя на диски, подключенные к H. Это намного быстрее, так как на один шаг меньше: Код: root@NAS:/mnt/family-tank/Incoming/pve_storage/template/iso# wget https://ftp.qubes-os.org/iso/Qubes-R4.2.1-x86_64.iso
--2024-04-07 14:07:47--  https://ftp.qubes-os.org/iso/Qubes-R4.2.1-x86_64.iso
Разрешение ftp.qubes-os.org (ftp.qubes-os.org)... 147.75.102.29, 2604:1380:4601:c500::1
Соединение с ftp.qubes-os.org (ftp.qubes-os.org)|147.75.102.29|:443... соединено.
Отправлен HTTP-запрос, ожидается ответ... 200 ОК
Длина: 6628073472 (6,2 ГБ) [application/octet-stream]
Сохранение в: ‘Qubes-R4.2.1-x86_64.iso’

Qubes-R4.2.1-x86_64.iso 100%[==================================>] 6,20GB 98,6MB/s в 63с

2024-04-07 14:07:30 (98,6 МБ/с) - ‘Qubes-R4.2.1-x86_64.iso’ сохранен [6628073472/6628073472]
Я могу скачивать прямо на VMhNAS на H или прямо на D в локальное хранилище, но я не могу скачивать на D и сохранять на VMhNAS. Моя следующая попытка была сделать простую команду копирования из локального хранилища на D в удаленное хранилище. Итак, здесь я беру известный хороший образ, который я ранее скачал на локальное хранилище на D в `/root/t` и отправляю его на хранилище VMhNAS на H: здесь нет части "скачивания из интернета". Вот результат, новый файл, который я скопировал в то же место, где был поврежденный файл, отлично работает: Код: root@pve:/mnt/pve/pve_storage/template/iso/t# cp /root/t/Qubes-R4.2.1-x86_64.iso Qubes-R4.2.1-x86_64.iso.CORRECT
root@pve:/mnt/pve/pve_storage/template/iso/t# sha512sum *
0bee5cc684a9c62c5ea0ca169daeb15b8da51a90eb4d1875064d0218b41f­db4e88a55091fe595e1998a02645d25d6ef06fc6e686efa1c2b207c0b667­9905042a  Qubes-R4.2.1-x86_64.iso
f4315893e7189782f56653197b4a2ab4be163900f31a4a2506bf157e2f31­8447bca09d6acb6f4abb13fb91d7bfa0687af333c20854085a2cc9490fe0­f3e07784  Qubes-R4.2.1-x86_64.iso.CORRECT
Итак, кажется, проблема возникает в моем случае, когда Wi-Fi ссылка перегружается? Есть какие-нибудь идеи, что проверить? Что еще я могу сделать, чтобы предоставить больше информации?

Ну вот ещё один эксперимент, который может вас удивить. Я только что скачал файл с командной строки, используя и wget, и curl. Оба запускались на хосте D и записывали данные удалённо на шару Samba, смонтированную из VMhNAS. Оба отработали:

```
root@pve:~# curl -o /mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.curl https://ftp.qubes-os.org/iso/Qubes-R4.2.1-x86_64.iso
 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100 6321M  100 6321M    0     0  17.0M      0  0:06:10  0:06:10 --:--:-- 9367k
root@pve:~# sha512sum /mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.curl
f4315893e7189782f56653197b4a2ab4be163900f31a4a2506bf157e2f31­8447bca09d6acb6f4abb13fb91d7bfa0687af333c20854085a2cc9490fe0­f3e07784  /mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.curl
```

```
root@pve:~# wget --progress=dot:giga -O /mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.wget https://ftp.qubes-os.org/iso/Qubes-R4.2.1-x86_64.iso
--2024-04-08 00:15:58--  https://ftp.qubes-os.org/iso/Qubes-R4.2.1-x86_64.iso
Resolving ftp.qubes-os.org (ftp.qubes-os.org)... 147.75.102.29, 2604:1380:4601:c500::1
Connecting to ftp.qubes-os.org (ftp.qubes-os.org)|147.75.102.29|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 6628073472 (6.2G) [application/octet-stream]
Saving to: ‘/mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.wget’

    0K ........ ........ ........ ........  0% 53.4M 1m58s
32768K ........ ........ ........ ........  1% 48.3M 2m3s
...
6422528K ........ ........ .                99% 16.2M 1s
6455296K ........ ........ .                100% 19.9M=4m56s

2024-04-08 00:20:54 (21.3 MB/s) - ‘/mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.wget’ saved [6628073472/6628073472]

root@pve:~# sha512sum /mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.wget
f4315893e7189782f56653197b4a2ab4be163900f31a4a2506bf157e2f31­8447bca09d6acb6f4abb13fb91d7bfa0687af333c20854085a2cc9490fe0­f3e07784  /mnt/pve/pve_storage/template/iso/Qubes-R4.2.1-x86_64.iso.wget
```

И curl, и wget смогли успешно скачать файл... Очень странный баг.

Привет @pvefanmark, ты в итоге смог разобраться с этой проблемой? Возможно, у меня та же самая. Моя конфигурация такая: у меня работает VM в proxmox, она скачивает файл, а потом отправляет его на Samba-сервер, который работает на том же хосте в proxmox, но в LXC. Скачиваемый файл корректный, но в мою Samba-папку записываются неправильные данные. У меня в сохраненном файле есть фрагменты данных, которые занулены. Два, которые я проверил, длиной 2800 байт и 3840 байт соответственно. Команда, которую я запускаю: Bash: wget https://huggingface.co/FireRedTeam/FireRedTTS-1S/resolve/main/pretrained_models.zip -O - | tee tmp.zip | sha256sum && sha256sum tmp.zip Пока что я не проверял память с помощью memtest86, чтобы исключить эту возможность.