Я думаю, що це правильна поведінка. 4k диски все ще повідомляють 512-байтові сектори на стороні інтерфейсу. Хоча вони внутрішньо стосуються секторів у 4k блоках.
Перемичка в більшості приводів просто дозволяє переключити сектор. На більшості дисків він зміщує секторову адресацію на 1. Причиною є невідома 4 ОС, як Winodws XP. Для того, щоб зрозуміти, вам потрібно знати, що Windows XP створює перший розділ, який починається з сектора 63 (так, це не помилка).
У більшості випадків Windows використовуватиме файлову систему з 4k одиницями розподілу (кластери NTFS). Отже, ви вважаєте, що коли ви читаєте кластер NTFS з традиційного накопичувача, він повинен прочитати лише 8 фізичних блоків. Досить просто.
Тепер накопичувач також використовуватиме 4k розмір сектора. Це цілком добре, оскільки ОС ніколи не буде читати менші кластери, ніж 4k, оскільки це найменша одиниця розподілу (якщо припустити, що ви не застосовували менші FS-кластери під час форматування). Як я писав, накопичувачі все ще піддають 512-байтові сектори на рівні інтерфейсу з причини сумісності. Але якщо ви читаєте лише один єдиний блок 512 байтів, то всередині накопичувач все одно зчитує 4k-сектор, а потім розщеплює його, щоб надсилати лише 512-байт через кабельний інтерфейс.
То де зараз проблема? ###
Проблема Windows XP полягає в тому, що як розділ вирівнюється до блоку 63 за замовчуванням. Це призводить до неправильного вирівнювання кластерів NTSF до фізичних блоків. Я створив невелику картинку, щоб проілюструвати це:
Як видно на малюнку в Windows XP, логічний кластер не вирівняний до фізичних 4k-блоків. Як результат, якщо Windows зчитує логічний кластер NTFS, він вимагає, щоб диск читав два блоки, а не лише один. Ще гірше, якщо вам просто потрібен один єдиний кластер NTFS, він зчитує два сектори і повинен об'єднати їх, щоб повернути в ОС лише запитувані дані.
Для операцій із записом це ще гірше. У цьому випадку накопичувач повинен прочитати два фізичні 4k сектори, а потім об'єднати їх вміст із вмістом нового кластеру NTFS, перш ніж він зможе зберегти обидва сектори на диску. Це означає, замість того, щоб просто замінити сектор на жорсткому диску, перезаписавши його, накопичувач повинен прочитати 8 к, об'єднати в буфер і записати 8 к. Це значно сповільнює операції запису.
Для запобігання непотрібного злиття HDD виробники додали "сумісність" хак, який можна ввімкнути за допомогою Jumper. Це просто збільшувати кожну 512-байтну адресу сектора на 1. В результаті перший розділ, створений Windows, запуститься в секторі 64, і відображення виглядає так:
Тепер будь-яке читання / запис логічного блоку 4k NTFS призводить до точного читання / запису одного фізичного сектора.
Звичайно, ця обробка взагалі не потрібна, якщо ви вже створюєте свої розділи, вирівняні за межами 4k-сектору. Наприклад, в Linux ви можете просто використовувати, fdiskщоб визначити, з якого блоку починається ваш розділ. Тож добре використовувати тут множину 8.
Windows запускає перший розділ у секторі 2048 AFAIR з Vista. Тож ця проблема тут вже не виникає.
ПОПЕРЕДЖЕННЯ : Якщо ви все ще використовуєте перемичку для роботи в 4k-готовій ОС, як Vista, Win7 або Win2k8 R2, це може насправді BREAK вирівнювання сектора. Причина полягає в тому, що накопичувач знову буде збільшувати адреси сектора на 1, в результаті чого перший розділ буде вирівняний до сектора 2049, що знову спричиняє значне падіння продуктивності.
Тому переконайтесь, що ви використовуєте 4-кратну ОС, яку ви видалите перемичкою, перш ніж розділити диск. У вашому конкретному випадку я думаю, що все повинно бути добре, доки ви перерозподілили привід із знятим перемичкою. Форматування накопичувача не має нічого спільного з вирівнюванням сектору та 4k-адресацією. Єдине, що вам слід переконатися під час форматування, це те, що ви не використовуєте кластери розміром менше 4k, оскільки 2k NTFS-кластери просто призведуть до необхідності все-таки зчитувати повний сектор 4k для кожного доступу до жорсткого диска з ОС. До речі: Використання 8k кластерів NTFS все ще цілком нормально, оскільки диск просто прочитає 2 сектори для кожної операції читання / запису NTFS.