имеют 2 папки на разные диски ведут себя так, как если бы они были одной папкой
У меня есть сервер с двумя жесткими дисками по 1 ТБ. У меня есть папка загрузок на / disk2 / uploads . Эта папка заполнила весь жесткий диск. Другой диск в основном пуст. Я хочу, чтобы на пустом диске была дополнительная папка, в которой размещались бы любые дополнительные закачки, которые не помещаются на первом диске.
Проблема в том, что моему веб-приложению необходимо знать, где находятся файлы. Одним из решений было бы, чтобы мое веб-приложение загружало все новые файлы на пустой диск, и когда приложению необходимо получить файл, оно увидит, существует ли он в новом месте, и если нет, оно проверит старое местоположение. . Я бы хотел решить эту проблему с помощью Linux.
Можно ли создать символическую ссылку (или что-то еще), которая позволила бы мне загружать новые файлы в / var / www / uploads и находить файлы в / disk2 / uploads из папки / var / www / uploads?
Например:
если / disk2 / uploads имеет папку1 и папку2 и / var / www / uploads имеет папку3 [1112416] ]. Тогда я бы хотел следующее:
> ls /disk2/uploads
folder1 folder2
> ls /var/www/uploads
folder1 folder2 folder3
Если такое решение существует, что произойдет, если существует /disk2/uploads/folder1/foo.log , и я попытаюсь загрузить foo.log в /var/www/uploads/folder1/foo.log ? Вероятно, для меня это не проблема, потому что все наши файлы имеют временную метку в их имени, но мне любопытно.
Я что-то здесь упустил? Почему бы просто не просто скопировать / переместить весь каталог загрузки на новый (пустой) диск и указать сервер на нем?
Если все, что вы хотите сделать, это линейно распределить данные по двум блочным устройствам (дискам, в данном случае), представляя единое пространство имён файловой системы, вы можете использовать LVM. Использование группы томов с двумя физическими томами и одним логическим томом, который выделяется для потребления всего необходимого пространства, будет очень простым. Это также позволит более эластично изменять размер томов. Это позволит решить проблему на уровне блоков, а выбранная файловая система сверху в значительной степени не имеет значения. Имеется ссылка на руководство RedHat о том, как это сделать в общем смысле .
То же самое можно сделать и с BTRFS, добавив несколько дисков в один пул файловых систем, а BTRFS имеет отличные возможности долговечности, которые LVM не обязательно включает, такие как контрольное суммирование и полностью онлайн-проверка файловой системы. Это было бы решением проблемы на уровне файловой системы. И вот общее руководство по BTRFS с несколькими устройствами.
Оба этих решения требуют копирования данных на новые файловые системы. Так что это не обязательно полный план миграции. Лично я бы, наверное, выбрал BTRFS в этом случае, если только вы не выполняете что-то вроде загрузки базы данных с тех же самых дисков, в которых я бы порекомендовал LVM и традиционные файловые системы.
Что касается переноса, то несколько промежуточных симлинков и файловая копия, вероятно, достаточно хороши. Однако, я не знаю, какое приложение вы запускаете, так что на вашу стратегию может повлиять это.
EDIT. Если подумать, то не используйте BTRFS на старых системах (что угодно до CentOS/RHEL 7 или SLES 12, например). Ранние пакеты в ядре 2.6 очень хорошо подходят для поддержки возможностей и стабильности.
EDIT. Ответ JDS напомнил мне о том, что вы, возможно, серьезно ищете способ (несколько, на самом деле) обеспечить полностью прозрачные оверлеи для межфайловых систем, которые позволят вам получать доступ к содержимому обеих систем различными унифицированными способами.
Я имею честное представление о личном опыте работы с unionfs, который отлично работает и довольно прост в использовании. Вы также можете посмотреть на aufs в зависимости от того, какие функции вам нужны. Эти файловые системы были бесценны для меня при переносе приложений и центров обработки данных.
.Нет никакого способа, с предоставленной вами информацией, чтобы просто связать эти каталоги вместе и заставить их выглядеть как один каталог.
Есть, однако, решения вашей проблемы. Однако, решения в основном требуют перестройки файловой системы. Это включает в себя такие шаги, как резервное копирование всех ваших данных, внесение значительных, разрушительных изменений в файловую систему, а затем восстановление данных.
Вы не предоставили достаточно подробной информации о сервере и существующей файловой системе, чтобы знать наверняка, какой подход лучше, но я могу сделать некоторые обоснованные предположения.
LVM - хороший вариант для создания одной "папки", которая охватывает несколько физических дисков. LVM достаточно легко настроить, но определенно требует некоторого планирования.
Самый простой способ перестроить существующий сервер с двумя отдельно смонтированными жесткими дисками в сервер с двумя жесткими дисками, смонтированными как один том LVM - это создать резервную копию всех данных и переустановить операционную систему с нуля. В современных установщиках ОС есть шаги, в которых LVM часть может быть настроена автоматически.
Если два диска емкостью 1 ТБ - это просто диски с данными, а ОС живет на другом диске, вы можете создать резервную копию всех данных, объединить два диска емкостью 1 ТБ в один LVM том емкостью почти 2 ТБ и смонтировать его в оригинальном местоположении. Затем восстановите данные.
Есть и другие файловые системы, которые предоставляют решение, похожее на LVM (например, ZFS), но все они сводятся к одному и тому же: 1) создать резервную копию; 2) восстановить fs как смежный логический том и смонтировать его в оригинальном месте, 3) восстановить данные.
.