none
DFS-R и первичная синхронизация RRS feed

  • Вопрос

  • Коллеги, приветствую.

    Подскажите, пожалуйста, кто в курсе.

    Необходимо средствами dfs-r синхронизировать "звездой" набор файлов между удалёнными подразделениями - центр является источником, а точки назначения - read only.

    Вопрос, если в точках назначения уже будет часть файлов, что передаёт источник (причём, само собой в той же каталожной структуре), эта файлы будут заново синхронизироваться или просто пройдёт сверка и их сервис повторно переливать не будет ?

    11 сентября 2019 г. 6:23

Ответы

  • Если у них одинаковый хэш (а именно по нему идентифицируются файлы) и дата изменения в центре будет старше, то перезальет.
    • Помечено в качестве ответа DmitryG_ 11 сентября 2019 г. 8:43
    11 сентября 2019 г. 7:51

Все ответы

  • Если у них одинаковый хэш (а именно по нему идентифицируются файлы) и дата изменения в центре будет старше, то перезальет.
    • Помечено в качестве ответа DmitryG_ 11 сентября 2019 г. 8:43
    11 сентября 2019 г. 7:51
  • Если у них одинаковый хэш (а именно по нему идентифицируются файлы) и дата изменения в центре будет старше, то перезальет.

    Понял, спасибо.

    А можно ещё слегка пояснить про Staging?

    Из документации понятно, что это каталог для временных файлов под перенос, так же там формируются некие кэши. Так же он подлежит автоматической очистке, судя по логам.

    Но не очень понятно из чего должен формироваться его квота? В одних статьях пишут про некие "сумму семи самых больших файлов в синхронизируемом каталоге", но судя по логу, квота может превышаться и репликация не приостанавливается.

    11 сентября 2019 г. 8:14
  • Не заморачивайтесь с этим. Это - некий буфер для хранения файлов при репликации. Если файл большой, то он будет дробиться (фрагментироваться) перед помещением в staging, поэтому репликация будет замедляться (по факту же особого влияние на процесс не обнаружил), по этой причине его рекомендуют делать бОльшим чем самый большой файл в группе реплики. Можете везде задать его 8/16 ГБ и забыть о нём.
    11 сентября 2019 г. 8:29
  • Не заморачивайтесь с этим. Это - некий буфер для хранения файлов при репликации. Если файл большой, то он будет дробиться (фрагментироваться) перед помещением в staging, поэтому репликация будет замедляться (по факту же особого влияние на процесс не обнаружил), по этой причине его рекомендуют делать бОльшим чем самый большой файл в группе реплики. Можете везде задать его 8/16 ГБ и забыть о нём.
    Спасибо большое за консультацию.
    11 сентября 2019 г. 8:43