Если я mount --bind /aв /bи если я mv /a/bigfile /b/это займет много времени (если исходный файл большой). Это фактически скопирует файл, а затем удалит исходный файл вместо того, чтобы просто обновить таблицу файлов файловой системы.
Я понимаю, как и почему это mount --bindработает. Как отметили другие, есть несколько хороших объяснений по этому поводу:
- Что такое привязное крепление?
- Почему я не могу создать «жёсткую ссылку» на файл из каталога «mount --bind» в той же файловой системе?
Есть ли способ сообщить mount, что a mount --bindнаходится в той же файловой системе, чтобы такие операции, как перемещение, выполнялись путем фактического обновления таблицы файлов файловой системы?
Я спрашиваю, как решить эту проблему, а не как ее понять: может быть, уже доступен патч ядра, о котором я не знаю, или отсутствующий параметр, который я еще не нашел (и т. д.).
Почему: В моей текущей настройке есть служба (nextcloud), которая поддерживает только mount --bind. Я не могу использовать символические ссылки. Если мне нужно, скажем, иметь общую папку внутри каждой учетной записи nextcloud, это должно быть с помощью bind. Я могу принять любое решение, которое работает с nextcloud, если оно сделано на уровне файловой системы/ядра. Это потому, что текущая настройка также включает доступ к этим файлам другими способами, например, ssh. Другими словами, я хотел бы иметь возможность перемещать файл, как в примере, с помощью любой команды или приложения.
решение1
Видимо, нет, т.страница руководстваrename(2)упоминает об этом:
EXDEVстарый путьиновыйпутьне находятся в одной и той же смонтированной файловой системе. (Linux позволяет монтировать файловую систему в нескольких точках, ноrename()не работает в разных точках монтирования, даже если одна и та же файловая система смонтирована в обеих.)
Если я правильно помню, монтирование привязки — это то же самое, что и простое монтирование одной и той же файловой системы несколько раз, т. е. после привязки не существует «источника» и «цели».
Есть еще одинотвечатьна другой вопрос по той же теме пару месяцев назад. В этом есть ссылки на обсуждение с разработчиками ядра. Так что идите и голосуйте за него.
решение2
У меня та же проблема с nextcloud и samba в контейнерах docker. Я решил ее, переместив все данные в nextcloud и позволив другим монтировать их из этого тома.
поэтому с точки зрения любых служб mv всегда находится только внутри одного связанного монтирования.
хотя не уверен, поможет ли это вам
решение3
Использование rsyncвместо этого mvдолжно решить проблему. Попробуйте использовать следующую команду
rsync -avP /a/bigfile /b/bigfile
Проблема в том, что точка просмотра mount --bindнаходится в ядре и скрыта от программ более высокого уровня, таких как mv. В отличие от mv, rsyncперемещает только измененные части файла.
Это объясняет примерноmount --bind Что такое привязное крепление?