Может ли клиент NTP динамически определять, когда нужно подключиться к серверам, без интеграции с конкретной системой конфигурации сети?
Para mí, el problema era que lo estaba usando (el mismo modelo de unidad )con una carcasa USB externa. Una vez que lo conecté directamente a un conector SATA, comenzó a ser reconocido como 3 TB. Si tiene el mismo problema y usa una interfaz USB para la unidad, intente conectar la unidad directamente a una conexión SATA.
Como señaló @phuclv, hay una gran explicación de esto en Superuser enhttps://superuser.com/questions/1101839/why-would-a-3tb-disk-show-as-being-746gib
нптд
В цитате упоминается ntpd, эталонный демон NTP. Полное сообщение включает список if-up.dперехватчиков скриптов в Debian. Дляntpd(иchrony)нет хуков-скриптов. Единственные сценарии, связанные с NTP -, предназначены для ntpdateи openntpd.
Если ntpdне получит ответа от сервера, я полагаю, что он повторно отправит пакет через 64 секунды.
Каков минимальный интервал между повторными попытками на неотвечающий NTP-сервер?
РЕДАКТИРОВАТЬ :Однако после нескольких неудачных попыток интервал повтора будет увеличен, в конечном счете, до 1024 секунд. (Оба значения настраиваются, но это значения по умолчанию ).
В документации ntpdтакже утверждается, что некоторые тайминги были выбраны «для того, чтобы модемный вызов мог завершиться». Похоже, что ntpdуже был спроектирован таким образом, чтобы он мог поддерживать сетевые подключения, которые создаются и теряются динамически, без необходимости явного уведомления. Однако соответствующий раздел, по-видимому, вводит в заблуждение. А учитывая указанный выше максимальный интервал повтора, я думаю, что настройки по умолчанию не будут работать во всех возможных случаях.
хрония
Напротив, в других источниках предполагается, что ntpплохо -подходит для коммутируемого доступа, отчасти из-за вопроса DNS. И этот chronyработает лучше, но он предназначен для использования перехватчиков скриптов. Пакет chrony -3.4 в Fedora Linux 29 включает скрипт ловушки, /etc/NetworkManager/dispatcher.d/20-chrony.
systemd -timesyncd
systemd-timesyncdинтегрируется сsystemd-networkd(и ничем другим ). В настоящее время он использует недокументированный интерфейс.
Когда systemd -timesyncd считает, что находится в сети, и ему не удается «подключиться», появляется повторная попытка каждые 30 секунд .
systemd-networkdизначально не имел интерфейса DBus . Точнее, тот, который у него был, еще не считался готовым .
Уже представляется возможным запускать скрипты ловушек, используя systemd-networkdсемантику.Хотя автоматически запускать все скрипты ловушек if-up.dбыло бы не очень хорошей идеей из-за некоторых различий в доступной семантике. (Как утверждается в ветке ошибок Debian, связанной с вопросом ). См.:
С помощью systemd -networkd выполните действие при изменении конфигурации сети
[ *] Это также звучит так, как будто дизайн ntpdдревний, поэтому он может не совсем соответствовать современным соображениям. Например. для планшетного устройства с питанием от небольшой батареи -.[ **] Вы хотите повторять попытку каждые 64 секунды, когда сервер не отвечает? РЕДАКТИРОВАТЬ :система не выполняет повторные попытки каждые 64 секунды бесконечно. После определенного периода недоступности интервал опроса увеличивается. («Подпрограмма опроса ()включает функцию, которая отменяет интервал опроса, если сервер становится недоступным...»)
[ **] Насколько я понимаю, «мобильные» -устройства класса спроектированы таким образом, что их можно оставить на ночь и приостановить работу большей части системы, за возможным исключением сетевого оборудования (, которое может реагировать к ARP без пробуждения процессора; возможно, он может вращать ключи шифрования, например. также для WPA ).