Это возможный дубликат перемещения файлов из одного раздела в другой на SSD
Когда я копирую файлы из C:\...\Downloads\ в C:\...\Desktop\ это происходит мгновенно, но если я скопирую тот же файл (1,12 ГБ) в D: это займет довольно много времени. Почему так?
Во-первых, ваш основной вопрос заключается в следующем:
Почему копирование занимает много времени между разделами на одном диске?
Ниже подробно рассмотрим, но один диск с несколькими разделами не является «одним и тем же диском» с точки зрения файловой системы. С точки зрения файловой системы раздел - это просто еще один «физический диск», даже если это просто «логически» выделенное пространство на большом родительском физическом диске, где находятся два раздела:
Читайте дальше для более подробной информации.
Примечание. Я использую терминологию Linux/Unix/Mac OS X, поскольку именно в этом заключается мой основной опыт, но базовая концепция применима к Windows и в действительности к любой ОС.
Почему ОС / ядро просто не перемещает информацию. байтов / секторов / адресных указателей / что бы ни выделялось этому файлу из одной таблицы FileSystem в таблицу FileSystem другого раздела?
Это связано с тем, что таблица inode, которая контролирует и управляет тем, какие сектора связаны с какими файлами, является конструкцией для каждого диска и каждого раздела.
Поэтому, когда вы копируете что-то из C: в C: все, что происходит, - это запись inode, которая редактируется на диске C: чтобы указать новый путь к файлу на том же диске C: .
Но когда вы копируете что-то из C: в D: данные должны быть скопированы, и на диске D: должна быть создана новая запись inode.
Допустим, вам интересно, почему бы просто не сохранить все данные диска на главном диске C: вместо того, чтобы делать это для каждого устройства, для каждого раздела? Что же происходит, когда этот диск или раздел перемещается на другую машину? Диск D: выглядел бы как пустое и неиспользуемое пространство без данных таблицы распределения. И если диск C: дает сбой в подобном сценарии, вы теряете не только диск C: но и более подробную информацию о файловой системе, подключенную к диску D: .
Вы также отредактировали свой вопрос, чтобы заявить это:
Я предполагаю, что разделение логично, а не физически.
И да и нет. Разделение логично на стороне таблицы разделов. Но на уровне файловой системы файловая система видит раздел, как если бы это был другой физический диск.
И вы также спросите это:
Так почему же ОС или контроллер FileSystem просто не копируют эти метаданные о
helloKitty.txtв таблицу других разделов?
Он делает копию метаданных из одного места в другое. Но он также копирует фактические данные файла, так как эти данные на D: не будут существовать, пока они не будут скопированы из C: И метаданные , которые он копирует ограничиваются основами о содержимом файлов , так как байты и сектор данные изменятся , когда он копируется из C: диск / раздел на D: диск / раздела.
Указатели байта не меняются, они являются абсолютными, поскольку раздел является логическим, а не физическим.
Раздел «логический» в контексте раздела. Данные, хранящиеся в файловой системе этого раздела, не являются «логическими» в контексте данных об отдельных файлах, поступающих в таблицу разделов. Это просто так, как оно есть, и раздел - как определено в Википедии - описывается следующим образом; Акцент мой:
Разделение диска - это разделение жесткого диска (HDD) на несколько логических блоков хранения, называемых разделами, для обработки одного физического диска, как если бы это было несколько дисков, так что в каждом разделе может использоваться другая файловая система.
Файловая система - это больше, чем просто адреса для содержимого каждого файла. Он также должен отслеживать, какие части раздела нераспределены («свободное место»), и сколько всего свободного места доступно. Если бы файловая система в разделе C: должна была хранить некоторые файловые данные в разделе D: , ей пришлось бы сначала изучить структуры файловой системы D: , чтобы найти свободное место, и пришлось бы пометить это пространство как выделенное в файловой системе D: так что данные не будут перезаписаны другим файлом, созданным в D: Позже, когда вы удалите файл, который, как представляется, находится в файловой системе C: , он должен будет снова войти в файловую систему D: чтобы пометить это пространство как свободное.
Проверка ошибок была бы проблематичной: обычно, если есть место, которое помечено как выделенное, но на самом деле не является частью какого-либо файла в структуре каталогов файловой системы, это считается ошибкой. Проверка согласованности (например, Windows chkdsk или Linux/Unix fdisk) либо помечает пространство как свободное, либо создает файл, сопоставленный с этим пространством, чтобы человек мог проверить данные и удалить их вручную. Но если рассматриваемые данные на самом деле являются частью файла в какой-либо другой файловой системе, это приведет к тому, что пространство будет помечено как свободное (либо сразу, либо когда кто-то удалит «восстановленный» файл), пока еще есть файл, использующий его.
Для безопасного размещения файлов за границами файловой системы две файловые системы должны постоянно «знать» о структурах друг друга в той степени, в которой они могут быть просто единой файловой системой, охватывающей несколько разделов. Некоторые файловые системы фактически поддерживают это: см. zfs и btrfs. Они действуют как своего рода RAID, встроенный в файловую систему: они могут создавать несколько разделов, даже на нескольких дисках, как один логический диск. Но разделы и диски зависят друг от друга; Вы не можете просто взять один и использовать его сам по себе.
Разные разделы похожи на разные диски в этом аспекте.
Блоки для каждого раздела назначаются последовательно, и вы предлагаете, чтобы диск автоматически перераспределял сам себя, назначая сектора, принадлежащие одному разделу, другому.
Такой подход будет очень подвержен ошибкам, ухудшит производительность диска и нарушит другие функции, такие как ведение журнала.
