Во-первых, это в значительной степени основано на мнении. Если вы спросите дюжину разных людей, вы, скорее всего, получите как минимум 3 -4 разных ответа.
Тем не менее, вот мое мнение по этому поводу:
/home
отдельно от /
. Основные рассуждения здесь в основном те же, что и всегда. Это затрудняет для ваших пользователей случайное использование всего пространства на /
и значительно упрощает сохранение пользовательских данных, если вам нужно повторно -установить. Кроме того, он изолирует одну из самых больших частей большинства систем от остальной системы, что может быть особенно полезно для управления резервным копированием. /tmp
и /var/tmp
отдельно от /
. Обе эти области используются для временного хранения, и количество изменений, которые это может вызвать в корневой файловой системе, может иметь значительное долгосрочное влияние на ее производительность. Кроме того, данные гарантированно будут временными с относительно коротким временем жизни. Это означает, что вам не следует создавать их резервные копии (, это просто пустая трата места ), и, вероятно, вы не будете копировать их при перемещении на новый диск. Тем не менее, /tmp
обычно должен быть экземпляром tmpfs
в наши дни, и /var/tmp
обычно тоже должен быть, если вы можете разместить все, что может быть там в ОЗУ. /var/cache
, но могут быть и другие, в зависимости от вашей конкретной системы. (Я думаю, что /var/cache
полностью охватывает его в Debian, хотя ). Это имеет много тех же преимуществ, что и изоляция /tmp
, /var/tmp
и /home
, но также дает вам четкую область, для которой вам не нужно резервировать (это кеш, если приложение ломается, потому что оно не может найти там данные, это плохо написанное приложение ), и поэтому его также не нужно копировать при перемещении на новый диск. /
. Это намеренно абстрактно, но включает в себя такие вещи, как страницы и данные для любых веб-сайтов, размещенных в системе, внутреннее хранилище -для любой базы данных или служб каталогов, предоставляемых системой, и другие подобные вещи. Изоляция этих данных дает два больших преимущества. Во-первых, он обеспечивает те же общие преимущества, что и разделение /home
и /
. Во-вторых, это, по крайней мере, частично отделяет производительность корневой файловой системы от производительности ваших томов данных. Это также позволяет вам перемещать эти наборы данных в другие конфигурации хранения, не влияя напрямую на остальную часть системы, что может означать разницу между периодом онлайн-обслуживания (, когда сервис просто ухудшается, но не полностью отключается )и вне линии -. /opt
и /usr/local
. Обратите внимание, что/opt
может содержать данные, управляемые вашим менеджером пакетов (, например, Dropbox и Google Chrome устанавливаются там ). это решение не подходит, поскольку автор вопроса позже указал, что речь идет не о двух больших файлах и не о локальном хранении tar-архива. Но, видя, что он по-прежнему относится к первоначальному названию вопроса, я решил оставить его для потомков.
Итак, проблема :Вы не можете "освободить" пространство, используемое файлом, пока не закончите его чтение; поэтому стандартные подходы к помещению файлов в tar
архив не могут работать, потому что это в основном:
Как видите,tar-архивы можно очень просто объединить. К сожалению, вы даже не можете скопировать содержимое одного файла в tar-архив, затем удалить его, а затем заархивировать следующий, потому что вам не хватит места до того, как первый закончит запись (, и нет способа POSIX усекая начало файла, который вы уже прочитали ). Итак, подход Камиля из комментариев выше не работает.
Таким образом, пока ваша файловая система не поддерживает релинковку частей файлов, это невозможно. (Единственными файловыми системами Linux, которые в настоящее время (июнь 2021 г.) поддерживают это, являются XFS и btrfs. Однако вам придется написать это программное обеспечение самостоятельно; вы захотите исследовать man ioctl_ficlonerange
, что позволит вам разделить память, используемую исходными файлами и архивными файлами.)
Тем не менее, наличие tar-файла размером 100 ГБ само по себе звучит довольно бесполезно; что ты собираешься с этим делать? Вы скопируете его на другое устройство или по сети, и в этом случае вам никогда не придется иметь его на своем собственном диске!
Вы бы просто создали этот tar-архив на лету вместо того, чтобы сначала генерировать его на своем жестком диске, а затем копировать. tar
все равно, записывает ли результат в файл, блочное устройство(tar
— это сокращение от T ape Ar chive, в любом случае! )или сетевой сокет.
То, что то, что вы хотите сделать, невозможно¹, может быть удручающим -, но я думаю, что вы решаете не -проблему.
¹ если только ваши файлы не находятся в одной и той же файловой системе XFS или btrfs, и вы знаете, что такое ioctl
и не хотите писать код
The tar archive will be uploaded to a long-term cloud storage solution (e.g. Amazon S3 Glacier Deep Archive, Google Cloud Archive Storage, etc.).
Ах! Так что вам никогда не понадобится tar-архив на вашем диске!
Вместо этого вы можете создать tar-архив на лету, загружая его на amazon S3 или куда-то еще. Кроме того, вам действительно нужно сжатие, потому что вы платите за объем.
Решение должно быть довольно простым:
tar c fileA fileB | aws s3 cp s3://mybucket/backup.tar -
: : : : : :
: : : : : \- read data from stdin
: : : : \- How to call the object
: : : \- unix pipe: the stdout of the
: : : tar command becoms the stdin
: : : of the aws command.
: \-----\- files to be compressed
\--compression command
Лично, особенно когда вы говорите, что у вас есть тысячи очень маленьких файлов, накладные расходы формата tar
становятся очень значительными. Я бы рекомендовал использовать
tar c --zstd file1 file2 … file1000 | aws s3 cp s3://mybucket/backup.tar.zst -
, чтобы на лету сжимать данные. Это экономит ваше время загрузки, платное пространство на вашем облачном хостинге и, как правило, это правильное решение.