Имеет ли какое-то преимущество сохранение пустого места в / home / $ username?
В отличие от опыта DopeGhoti, флаг - bwlimit ограничивает передачу данных с моим rsync (v3.1.2).
test:
$ dd if=/dev/urandom bs=1M count=10 of=data
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0871822 s, 120 MB/s
$ du -h data
10M data
$ time rsync -q data fast
0.065 seconds
$ time rsync -q --bwlimit=1M data slow
10.004 seconds
(примечание: мой вывод time отличается от большинства вызовов time (функция zsh ), это время не редактировалось me)
Иначе, возможно, что-то вроде двойного -exec в find . Я полагаю , что rsync -R должен создавать и копировать родительские папки, но если этого не произойдет, тогда cp --parents должен.
$ find /failing/usb -exec rsync -R {} /somewhere/safe/ \; -exec sleep 1 \;
Примечание : также ознакомьтесь с ddrescue , возможно, это именно то, что вы ищете :)
Это зависит от того, для чего вы используете свою систему. Для почтового сервера или веб-сервера мне нужно больше свободного места в / var. Для настольной системы я обычно помещаю / home в программный массив RAID-1, и у меня остается много свободного места на /, поэтому я могу выгружать большие вещи, которые в некоторой степени расходуются (загруженные isos дистрибутива, различные виртуальные машины временного использования и т. Д.).
В принципе, какие части вашего дерева каталогов останутся статичными после первоначальной установки / настройки, а какие будут расти / сжиматься / использоваться чаще?
Это зависит от используемой файловой системы.
С ext4 , традиционной и все еще довольно распространенной файловой системой, которая происходит от ext2 (и с которой она в некоторой степени обратно совместима), ядро будет разбрасывать файлы по всем на жесткий диск, чтобы избежать фрагментации файлов. Однако для этого требуется некоторое свободное пространство на блочном устройстве, содержащем файловую систему. Если объем доступного дискового пространства очень мал, тогда ядро не может организовать файлы эффективным образом, и произойдет фрагментация (и, как следствие, проблемы с производительностью).
Это причина, по которой файловые системы ext * по умолчанию выделяют 5% своего доступного пространства только для root-доступа. Хотя это можно изменить, это делать не рекомендуется по очевидным причинам. Однако, даже если вы не сделаете эту модификацию и закончите запись на диск до тех пор, пока вы не израсходуете все 95% доступного дискового пространства, производительность все равно может пострадать, если эта ситуация останется неизменной в течение длительного времени, особенно если вы почти не хватает места и начинаем записывать в раздел большой файл.
Вкратце: да, это может вызвать проблемы с производительностью при доступе к этой файловой системе, но есть встроенная настройка безопасности, которая должна предотвратить худшее из них.
Другие файловые системы имеют другие функции в этой области и могут иметь, а могут и не страдать от тех же проблем; например, ZFS использует семантику копирования при записи, поэтому он может повторно оптимизировать место хранения фактических данных каждый раз, когда он записывает новый блок. Однако, если вы не знаете, какую файловую систему вы используете, скорее всего, вы используете ext4 , и все вышесказанное применимо.
Да, всегда желательно иметь немного свободного места (скажем, 5%), иначе производительность вашей системы может упасть из-за фрагментации файловой системы (на механических жестких дисках), из-за которой головки вашего диска будут перемещаться вперед и назад для чтения файла (что намного медленнее, чем чтение непрерывного файла).
См. Влияет ли место на жестком диске на производительность? в ServerFault.
[обновление]
Обратите внимание, что в файловых системах Linux ext2 / 3/4 небольшой процент блоков зарезервирован для root. Они также защищают вашу систему от чрезмерной фрагментации (подробнее см. Зарезервированное пространство для root в файловой системе - почему? ). Вы можете увидеть количество зарезервированных блоков в файловой системе ext с помощью следующей команды:
dumpe2fs -h /dev/sdxN | grep ^Reserved