копирование файлов (cp и rsync )на внешний жесткий диск вызывает ошибки ввода-вывода и потерю данных в месте назначения
Why the interfaces file didn't mention my ens33 interface though it was fully operational?
Потому что, как уже упоминалось в комментарии, существует движение по замене «традиционного» способа использования /etc/network/interfaces«новым» способом использования systemdи сетевого менеджера.
Why "resolvconf" does prevent to use "resolv.conf" and force to use "base" and writes itself the DNS properties in "interfaces", and someone tells me here it shouldn't be written that way?
Не уверен, что правильно понял вопрос, но давным-давно, когда сети были статичными и в больших организациях, resolv.confписалось от руки, а DNS-сервер был частью организаций. Это было еще до того, как в Windows появилась правильная сеть (или прочее Novell ). Затем все и его дядя начали иметь дома Интернет, с домашним маршрутизатором, выступающим в роли DHCP-сервера, DNS-прокси, а провайдер предоставил DNS. Поэтому был добавлен дополнительный уровень, который автоматически генерирует resolv.confна основе информации, предоставленной DHCP.
Why did the parameters of the "ens33" interface disappear after reboot?
Если я правильно понял ваше описание, они не исчезли.
ifup: /etc/network/interfaces:16: unknown or no address type and no inherits keyword specified
означает, что в файле была синтаксическая ошибка,и
ifup: couldn't read interfaces file "/etc/network/interfaces"
означает, что из-за ошибки он не смог прочитать информацию в файле (конечно же может прочитать сам файл, иначе бы он не жаловался на ошибку в строке 16 ).
Which, in the end, are the effective files that define the properties of a LAN adapter?
Это полностью зависит от того, используете ли вы новую или традиционную систему. (Лично мне новая система не нравится, поэтому я не могу на это ответить; и даже традиционная система со временем приобрела множество крючков, которые могут изменить конечный результат. По уважительной причине, потому что бывают ситуации, когда вам это нужно ).
Более полезный вопрос: :"какие файлы мне нужно изменить, чтобы правильно настроить сеть для этой машины?" И это зависит от вашей сети -для типичной домашней сети с DHCP-сервером в домашнем маршрутизаторе ответ «вам не нужно ничего менять». Если вам нужен конкретный ответ, отредактируйте вопрос и опишите свою сеть.
To these 4 questions, I've been searching the web and the "man" pages, but couldn't find a single answer.
Это потому, что старые материалы в Интернете (и многие справочные -страницы )были написаны, когда существовал только «традиционный» метод, а люди, пишущие о новом методе, часто не упоминают старый метод..
This justifies the title of this page in my opinion, although it seems I've deceived three gurus who, instead of trying to help a beginner, sacrificed a bit of their so precious time to minus my question...
Если я могу добавить сюда свое личное мнение :Нейтрально сформулированные вопросы, которые оставляют в стороне ваши личные чувства, а также идеи о том, как «все должно быть», помогут избежать отрицательных голосов.
Спасибо за помощь.
Теперь я решил проблему. Я переформатировал диск в ext4 и после этого использовал команду
rsync -avhW source dest --inplace --exclude=".*/"
где
-a is for archive, which preserves ownership, permissions etc.
-v is for verbose, to see what is happening
-h is for human-readable, so the transfer rate and file sizes are easier to read
-W is for copying whole files only, without delta-xfer algorithm which should reduce CPU load
--inplace tells rsync to not create a temporary copy of the file to be transferred, which is then copied to the destination. This should speed up the process.
--exclude=".*/" is for excluding all hidden folders
Средняя скорость передачи данных для 392 ГБ составила 81,3 МБ/с, что намного выше, чем у меня было до переформатирования диска.
На этот раз в dmesg не было ошибок.
Обратите внимание, что я не пытался создать новый раздел NTFS на диске, чтобы проверить, был ли причиной проблемы конкретный раздел NTFS, установленный на заводе, или проблема была вызвана самой NTFS. Это, к сожалению, означает, что у меня нет полного ответа на вопрос, в чем заключалась проблема. Я также не пытался увеличить пороги времени ожидания, но, учитывая гораздо более высокую скорость передачи данных на этот раз, я бы сказал, что увеличение порогов времени ожидания в лучшем случае будет обходным путем, а не решением.