Скажем, у меня есть дополнительный жесткий диск, который был дефрагментирован и оптимизирован, чтобы данные представляли собой аккуратный непрерывный блок без отсутствующих пробелов / кластеров. Как сплошная кирпичная стена.
-> Представьте себе такую картинку для хранения файловой системы:
[(Data1)(data1)(data2)(data2)(данные3)(данные3)(Data4)(Data4)(данные 5)(data6)(пусто)(данных7)]
Каждый из элементов в (..) имеет размер блока, они могут быть блоками 4k, 8k, 16k, 32k, и т.д., в зависимости от ваших потребностей в хранилище.
Если я копирую файл с таким же именем и перезаписываю его на дополнительный диск, хранятся ли данные в одном и том же пространстве / кластере?
-> Да, хотя вы действительно не знаете.
Это зависит от размера копируемого файла.
Если файл был изменен, чтобы добавить больше данных в файл или удалить данные в файле, он может использовать больше блоков данных или меньше блоков данных. Для файла файловой системы 4k на блок, который использовался для хранения файла, этот файл должен занимать пространство в кластерах 4k. Если бы данные использовали только 5 КБ, то для хранения файла потребовалось бы два кластера 4 КБ.
Что, если файл меньше, это создаст новый пробел в кластерах?
Если файл был меньше, этот пробел в действительности является просто неиспользуемым пространством данных в кластере, исходя из ближайших блоков, необходимых для хранения нового файла.
Что, если файл больше, часть данных заполнит кластер, а затем будет использовать его в конце свободного диска, делая его фрагментированным?
-> Вообще-то да, хотя сегодня для файловых систем это проблемы, которые не так заметны.
Если у вас нет процесса чтения / записи непрерывно в блочной файловой системе ... и для этого случая я просто создал бы ram-диск только для того, чтобы этот процесс работал.
Итак, я бы посоветовал вам сосредоточиться на многих других факторах, влияющих на производительность, таких как использование prelink и preload ... и изменение значения 'vm.swappiness = 10' в файле /etc/sysctl.conf, если у вас есть система debian ,
Ура Рик :)
