» Наилучшее разбиение диска на разделы

Цитата:

когда физические секторы жёсткого диска начинаются с блока LBA 2048.

Цитата:

Ржунимагу.

9285, подробности про выравнивание давай!

driver29

Цитата:

что они сейчас производят?

http://www.wdc.com
Много чего производят, почти все модели у них с AF. Сами посмотрИте.


Цитата:

Так что в теме «Наилучшее разбиение диска на разделы» неплохо тоже заострить внимание пользователей на размер сектора диска, которого они собирается разбивать на разделы!

Да, неплохо. Но лучше для этого написать немного теории о AF в соотв. теме и дать туда ссылку. Т.е. просто указать, какие проблемы могут быть и что именно необходимо выравнивать, без указания конкретного "выравнивающего ПО".


Цитата:

Windows Vista и Windows 7 умеют работать с секторами разного размера, то есть они, автоматически выполняют выравнивание 512-байт секторов, в случае, когда физические секторы жёсткого диска начинаются с блока LBA 2048.

Я тоже так умею: "блоки LBA и жёсткого диска выполняют выравнивание с Windows 7 размера, то есть они, умеют работать автоматически 512-байт секторов, в случае, когда физические секторы начинаются с секторами разного Windows Vista" :) Путаетесь вы в терминологии, вот и получается бессмысленный набор слов.


Цитата:

То есть в Windows XP эти жёсткие диски работают медленнее, чем в Windows Vista и Windows 7!

В Windows XP AF-диски нормально работают, потерь скорости не будет, если ФС, с которой работаем, выровнена. Равно как работа с разделом с невыровненной ФС на таком диске будет медленной независимо от ОС.


Цитата:

Оригинал обзора:

Обзоры оттуда да в приличном обществе :) Как вообще можно воспринимать всерьез сей ресурс после таких позоров обзоров? Да и с арифметикой у мегапозорообзорописателей проблемы: "если стандартные жесткие диски имеют физические сектора размерами по 512 байт, то жесткие диски с технологией Advanced Format имеют физический сектор размерами 4 килобайта, то есть содержат в себе четыре стандартных сектора." (выделено мной)

тестовый архив с кучей мелких файлов испытанный в теме AF винтов, показал примерно следующие результаты распаковка:
AF выровненный 1 минута 30 сек
AF невыровненный 1 минута 45 сек
нативный винт с 512 сектором 15 секунд

нужна совместимость со старым софтом - не выравнивай, не нужна выравнивай, все равно будет тупить при большом количестве обращений к диску. семерка, хп, 2003, хп с 2003-ми дровами - роли не играет

Добавлено:
причем фигня загадочная. восстанавливаешь на него образ акронисом - скорость не отличается от нативного. возможно из за того что записи в файловой таблице выровнены на 512. но чета мы там мучились так и не смогли ничего добиться.

bomzzz

Цитата:

AF выровненный 1 минута 30 сек

Выровненный чем, говнософтом? Тогда не удивительно.

Цитата:

«Насколько актуален Advanced Format
Естественно, в условиях старой размерности сектора по 512 байт не может продолжаться дальнейшее развитие жестких дисков, т.е. увеличения их объема. Рано или поздно жесткие диски со стандартными секторами в 512 байт полностью исчезнут с рынка. Внедрение технологии Advanced Format было начато в 2009 году, массовый пользователь увидел новые жесткие диски в 2010 году. Предполагалось, что стремительное внедрение нового формата будет закончено уже в 2011 году, а в 2012 году стандартные жесткие диски с секторами по 512 байт вовсе покинут прилавки магазинов. Объективно мы не наблюдаем массового вытеснения. Скорее можно отметить параллельное существование на рынке жестких дисков со стандартными 512 байтными секторами и жестких дисков с секторами по 4 килобайта в рамках технологии Advanced Format».
Оригинал обзора: http://megaobzor.com/Advanced-Format-zhestkih-diskov-4-kb-vmesto-512-bayt-na-sektor---zachem-nuzhno-.html

dimitriy7, - начну с последней Вашей фразы:
Цитата:

Обзоры оттуда да в приличном обществе Как вообще можно воспринимать всерьез сей ресурс после таких позоров обзоров? Да и с арифметикой у мегапозорообзорописателей проблемы: "если стандартные жесткие диски имеют физические сектора размерами по 512 байт, то жесткие диски с технологией Advanced Format имеют физический сектор размерами 4 килобайта, то есть содержат в себе четыре стандартных сектора." (выделено мной)

dimitriy7, - у Вас с головкой все нормально? Вы сами поняли, что написали? Это про какие «четыре стандартных сектора» Вы тут пишете?



driver29 писал:
Цитата:

Жёсткие диски новой линейки EARS Western Digital, разбитые средствами Windows XP для нормальной работы операционной системы Windows XP необходимо выравнивать
Если эти диски разметить программой Acronis True Image Home 2011, то их выравнивать не нужно …

dimitriy7 писал:
Цитата:

В Windows XP AF-диски нормально работают, потерь скорости не будет, если ФС, с которой работаем, выровнена. Равно как работа с разделом с невыровненной ФС на таком диске будет медленной независимо от ОС.

Я понимаю под выравниванием сдвиг начала всех разделов (Start LBA) жёстких AF дисков на величину кратную 8, - для исключения операции чтения-модификации-записи, вносящей дополнительную задержку из-за дополнительного вращения пластин жёсткого диска AF в ОС «WindowsXP» и «Windows Vista — без пакета обновления Service Pack 1»!

Не выровненным, - считаю жёсткий AF диск, разбитый в ОС Windows XP (и более ранними версиями Windows) (tart LBA первого раздела = 63) без использования служебной программы Diskpart, позволяющей задавать Start LBA.

P.S.
Программой Acronis True Image Home 2011, операционными системами Windows Vista — с пакетом обновления Service Pack 1 или более поздней версии и Windows 7 при разбивке AF диска создаются разделы с выравниванием.

driver29

Цитата:

у Вас с головкой все нормально? Вы сами поняли, что написали? Это про какие «четыре стандартных сектора» Вы тут пишете?

Это не он пишет, а они. То что 4096/512 у них получилось 4.
ECC и метка синхронизации при этом конечно не учитывают.

driver29
Очень не хотел переходить на личности... Но тем не менее -- сделай одолжение, протри очки и внимательно перечитай тот "обзор", ссылку на который ты сам же дал. И мой предыдущий пост тоже перечитай, кавычки там не просто так, бред про "четыре сектора" есть цитата.

dimitriy7 писал:
Цитата:

и внимательно перечитай тот "обзор", ссылку на который ты сам же дал.

dimitriy7, - Вы откланяетесь от темы. Я Вам ранее привёл ссылку, показывающую, что диски HDD 2 Tb SATA 6Gb / s Western Digital Caviar Green < WD20EARX> 3.5" 64Mb ещё есть в продаже. Возражая Вашему утверждению, что сейчас выпускаются 90% AF дисков я привел ссылку показывающую, что это не так!
Вы же прицепились к не имеющей отношения к теме обсуждения фразе, - не указав даже в какой части текста она находится!
unreal666 писал:
Цитата:

Это не он пишет, а они. То что 4096/512 у них получилось 4.
ECC и метка синхронизации при этом конечно не учитывают.

Да всё они учитывают!

Цитата:

«Как можно понять из названия самой технологии, Advanced Format, предполагает расширенный режим форматирования жесткого диска. При этом если стандартные жесткие диски имеют физические сектора размерами по 512 байт, то жесткие диски с технологией Advanced Format имеют физический сектор размерами 4 килобайта, то есть содержат в себе четыре стандартных сектора». Оригинал обзора: http://megaobzor.com/Advanced-Format-zhestkih-diskov-4-kb-vmesto-512-bayt-na-sektor---zachem-nuzhno-.html

В этой фразе речь идет о физических секторах!

Цитата:

Advanced Format - больше места на диске Переход на новый формат Advanced Format подразумевает увеличение свободного пространства жесткого диска. При разметке жесткого диска на сектора по 512 байт, каждый сектор дополняется 50 байтами для кода коррекции ошибок, тем самым пользователь получает лишь 87% фактического места на магнитном диске жесткого диска. В случае использования технологии Advanced Format на каждый сектор размером в 4 килобайта используется 100 байт пространства для кода коррекции ошибок, тем самым экономится 50% пространства и пользователь получает возможность использования 96% физического пространства каждого магнитного диска». Оригинал обзора: http://megaobzor.com/Advanced-Format-zhestkih-diskov-4-kb-vmesto-512-bayt-na-sektor---zachem-nuzhno-.html

unreal666
Зря ты упомянул про дополнительные данные. У него и до этого пёрло неплохо, а сейчас вообще фонтан.

driver29

Цитата:

В этой фразе речь идет о физических секторах!

Вы не то выделили, над чем здесь все ржут.
Цитата:

«Как можно понять из названия самой технологии, Advanced Format, предполагает расширенный режим форматирования жесткого диска. При этом если стандартные жесткие диски имеют физические сектора размерами по 512 байт, то жесткие диски с технологией Advanced Format имеют физический сектор размерами 4 килобайта, то есть содержат в себе четыре стандартных сектора». Оригинал обзора: http://megaobzor.com/Advanced-Format-zhestkih-diskov-4-kb-vmesto-512-bayt-na-sektor---zachem-nuzhno-.html

Цитата:

Вы не то выделили

Пытаюсь гадать о чём там dimitriy7 чирикает ...


Цитата:

Это не он пишет, а они. То что 4096/512 у них получилось 4.

, - а этого они не пишут!

driver29

Цитата:

Да всё они учитывают!

Ничего они не учитывают. У них слово "физический" идет в противовес "логическому", которыми оперирует ОС (+ перемычка на самом винте для эмуляции).
Эти грамотеи взяли инфу из документа WD + переработали ее криворукие горематематики с выкидыванием нужной инфы.
Оригинал инфы от WD дан в конце поста.

Цитата:

то есть содержат в себе четыре стандартных сектора

фиговая математика

Цитата:

тем самым экономится 50% пространства

50% относительно чего? тоже фиговая математика, т.к. при использовании AF экономится 7-11% пространства. ()

Цитата:

То, что раньше размещалось в 8-и физических секторах, - размещается в 4-х физических секторах!

тоже фиговый математик. То что раньше размещалось в 8 физических секторах, сейчас размещается в 1-м физическом секторе!

---

ЗЫ.

Инфа от WD:

Цитата:

Применение технологии Advanced Format позволяет использовать одно поле Sync/DAM, один межсекторный промежуток и одно поле ECC вместо восьми промежутков и полей каждого из типов. Таким образом удается выиграть примерно 7—11% полезного дискового пространства. Носители Advanced Format также лучше сохраняют целостность данных, так как в них применяется более эффективная система исправления ошибок с более длинными кодовыми словами ECC.
В дисках с технологией Advanced Format используются соответствующие пластины. Пластины Advanced Format разбиты на физические секторы Advanced Format размером 4096 байт, состоящие из восьми логических секторов по 512 байт.

---

Картинки от Hitachi:



==================================================================



==================================================================

driver29

Цитата:

Пытаюсь гадать о чём там dimitriy7 чирикает ...

Специально для тебя поясню, чтобы не гадал:
1. Ты зачем-то дал ссылку на обзор, вот эту:
Цитата:

Оригинал обзора: http://megaobzor.com/Advanced-Format-zhestkih-diskov-4-kb-vmesto-512-bayt-na-sektor---zachem-nuzhno-.html

2. В этом обзоре есть фраза:
Цитата:

если стандартные жесткие диски имеют физические сектора размерами по 512 байт, то жесткие диски с технологией Advanced Format имеют физический сектор размерами 4 килобайта, то есть содержат в себе четыре стандартных сектора.

Если не слепой, сам её найдешь. А если не дурак, то сам поймешь, что 4 раза по 512 не равно 4096, и что не может быть никакого доверия к такому "обзору".
3. Заметь, я тебе не хамил, не провоцировал, на "вы" называл -- так почему ж ты позволяешь себе меня оскорблять?
4. И не фиг замусоривать сию тему, если уж так хочется поболтать -- милости прошу сюда: Ссылка

Пришла в голову идея: раз жёсткий диск имеет форму цилиндра (кольца), то и разбивать его на разделы нужно так, чтобы ширина колец, образуемых разделами, была одинаковой, чтобы уменьшить нагрузку на диск. Поэтому сделал электронную таблицу с расчётами, позволяющую, зная размер и скорости в начале и конце диска, определить размеры разделов при разметке на 2 и 3 раздела. Файл можно открыть, например, программами OpenOffice или LibreOffice.

brRamires
А зачем резерв в самом начале? Там где самые скоростные характеристики?
И о какой равномерности нагрузки идёт речь (какая связь с шириной)?

brRamires

Цитата:

Пришла в голову идея: раз жёсткий диск имеет форму цилиндра (кольца), то и разбивать его на разделы нужно так, чтобы ширина колец, образуемых разделами, была одинаковой, чтобы уменьшить нагрузку на диск.

Пришла в голову хрень.

Цитата:

А зачем резерв в самом начале? Там где самые скоростные характеристики?

Это необязательно (если поставить 0), если диск используется не только для данных, но и для ОС, т.к. скорость в начале диска выше => быстрее грузится система и т.д.

Цитата:

И о какой равномерности нагрузки идёт речь (какая связь с шириной)?

Например, при записи данные записываются не только там, где файл, но и в MFT (информация о файле - метаданные), а значит, если записываемые данные находятся в конце раздела, то при разбиении на разделы головкам диска не так далеко ездить от MFT к самому файлу, т.е. сокращается маршрут, которые преодолевают головки диска. То же самое при чтении.


Цитата:

Пришла в голову хрень.

Что именно не понравилось?

brRamires

Цитата:

то при разбиении на разделы головкам диска не так далеко ездить от MFT к самому файлу, т.е. сокращается маршрут, которые преодолевают головки диска.

Это в теории, а на практике винда в первую очередь кеширует $MFT (если позволяет память, то вообще целиком) при первом же обращении к разделу.


Цитата:

Пришла в голову хрень.
Что именно не понравилось?

Ну почитайте про формат современных дисков, про зонное форматирование, и поймите -- "ширина кольца" давным-давно слабо коррелирует с его объемом и скоростными характеристиками.

brRamires
Про то, как происходит работа с MFT уже сказано.
Да и практика восстановления данных показывает что не всегда она располагается в начале раздела.
К тому же, с данными (в основном) работа идёт не так интенсивно и выгоды от такой равномерности маловато.
Небольшие разделы более подвержены дефрагментации (при заполнении) и через время может возникнуть проблема перебрасываия данных между разделами.
Уже ранее писал, но оптимальность разбивки определяется задачами. И есть обоснование отделать систему от данных, редкоиспользуемые данные (образы системы, архивы, драйвера и т.п.) от основных.
Но дробить данные вообще и именно в таком контексте - это если нечем другим заняться. ИМХО.

Цитата:

Это в теории, а на практике винда в первую очередь кеширует $MFT (если позволяет память, то вообще целиком) при первом же обращении к разделу.

Чтобы проверить, как оно работает на самом деле, нужна какая-нибудь спец. программа. Не думаю, что такая вообще существует. Моё исследование было чисто теоретическим. По крайней мере, при записи на диск, экономия имеет место быть, но насколько она велика, это нужно выяснять отдельно.

Цитата:

Ну почитайте про формат современных дисков, про зонное форматирование, и поймите -- "ширина кольца" давным-давно слабо коррелирует с его объемом и скоростными характеристиками.

Ну так понятно, что на внешних дорожках влезает больше данных, чем на внутренних, поэтому там выше и объём, и скорость.

Цитата:

Про то, как происходит работа с MFT уже сказано.
Да и практика восстановления данных показывает что не всегда она располагается в начале раздела.

Расположение MFT можно изменить при помощи программы UltimateDefrag, но где бы она не находилась, среднее расстояние между файлом и метаданными будет ниже при разбиении на большее количество разделов, хотя соглашусь, что реальная выгода от такого разбиения в плане нагрузки на механику диска может быть небольшой.

brRamires
Даже если отбросить ранее упомянутое кэширование, то по твоей логике нужно разбивать диск на кучу маленьких разделов?
Мне вообще почему то припомнились времена, когда начали активно продвигать всякие энергосберегающие технологии. В том числе отключение винта после нескольких минут простоя. Тогда не все винты оказались к этому готовы и ломались от этих вкл-выкл. Сколько тратилось энергии на производство нового винта, попытки восстановления данных - вряд ли оно могло сравниться с той "экономией". В общем то "овчинка не стоит выделки".

Цитата:

Даже если отбросить ранее упомянутое кэширование, то по твоей логике нужно разбивать диск на кучу маленьких разделов?

Нет, оптимальной я как раз считаю разбивку на 2 раздела, с размерами, согласно расчётам, где-то от 55-45% до 60-40%.
Вопрос с кешированием MFT в ОЗУ, кстати, весьма спорный. У меня, например, есть раздел с MFT = 300 Мб. Не может быть, чтобы вся MFT была кеширована, а есть ведь и другие разделы.

Цитата:

Вопрос с кешированием MFT в ОЗУ, кстати, весьма спорный. У меня, например, есть раздел с MFT = 300 Мб. Не может быть, чтобы вся MFT была кеширована, а есть ведь и другие разделы.

Ну во-первых у вин-7 кеш может занимать хоть всю свободную память, так что разместить 500Мб не проблема. Кстати, замечали: при первом доступе к разделу с большим $MFT происходит некоторая задержка, а при последующих нет?
Во-вторых, никто и не говорит, что MFT всегда кешируется полностью и со всех разделов. Читаем внимательно ту мою фразу, с которой началось обсуждение:
Цитата:

на практике винда в первую очередь кеширует $MFT (если позволяет память, то вообще целиком) при первом же обращении к разделу.

Т.е. если мы раздел не трогаем, то его MFT и не кешируется. А если трогаем, но $MFT большой и/или памяти мало, то может и не сразу и не целиком (опять же, можно по вышеозначенной задержке прикинуть, сколько примерно будет считано в кеш). Плюс периодически он сбрасывается из кеша на диск.
Кстати:
Цитата:

Чтобы проверить, как оно работает на самом деле, нужна какая-нибудь спец. программа. Не думаю, что такая вообще существует. Моё исследование было чисто теоретическим

[more=а что мешает проверить на практике?] Для этого много не надо: зайти проводником/тотал-коммандером/и-т-п на ntfs-раздел, создать файл с уникальным именем и выйти с раздела. И тут же любым способом сохранить на другой раздел $MFT с подопытного (тот же winhex в режиме прямого доступа умеет, только сначала разберитесь как это делать), плюс сбросьте полный дамп ОЗУ. И затем поищите в MFT и дампе запись о вашем новом файле. Так вот: 100% в памяти обнаружится MFT подопытного раздела, плюс скорее всего запись о новом файле окажется только в памяти, но не в файле MFT...
Мне просто сейчас не до того, но на неделе сам поэкспериментирую, проверю[/more]

Ну и в-третьих: кроме виндового файлокеша есть еще куча причин, делающих вашу теорию бессмысленной на практике.
Вот подкину задачку, скорее даже информацию к размышлению:
Вы ведь уже ознакомились с низкоуровневым форматом, с зонным форматированием? Так вот вопрос: о реальном формате, конфигурации голов, делении на зоны, распределении плотности по головам и зонам вы ничего не знаете (и знать не можете, эти параметры очень сильно различаются даже для разных экземпляров одной модели, и узнать их можно только с помощью спец. технологических программ, а порой вообще только через терминал), и как же безо всей этой информации вы будете пересчитывать сантиметры на магнитных дисках в гигабайты? Ведь ваши "где-то от 55-45% до 60-40%" гигабайт реально могут превратиться в "где-то от 10-90% до 90-10%" сантиметров.

Цитата:

Ну во-первых у вин-7 кеш может занимать хоть всю свободную память, так что разместить 500Мб не проблема. Кстати, замечали: при первом доступе к разделу с большим $MFT происходит некоторая задержка, а при последующих нет?
Во-вторых, никто и не говорит, что MFT всегда кешируется полностью и со всех разделов.

Это легко проверить. Пререзагружаем комп, запускаем Resmon.exe и Диспетчер задач, делаем скриншот, открываем Проводник, лазаем по папкам на всех разделах, делаем второй скриншот. Результат:

Как видно, ни о каких 300 Мб и речи не идёт.
Кроме того, никакой кеш вас не спасёт во время дефрагментации, головки будут постоянно беагать от MFT к файлам, так что это ещё один аргумент в пользу двух разделов против одного.

Цитата:

и как же безо всей этой информации вы будете пересчитывать сантиметры на магнитных дисках в гигабайты? Ведь ваши "где-то от 55-45% до 60-40%" гигабайт реально могут превратиться в "где-то от 10-90% до 90-10%" сантиметров.

Ничего подобного быть не может. Зависимость "сантиметры-гигабайты" прекрасно отражает скорость считывания данных. Посмотрите на мой первый скриншот на предыдущей странице: там математически выведенный график совпадает с реальным графиком, полученным программой HDTune.

brRamires
Не возникала мысль о том, что MFT уже закэшированна (на стадии монтирования раздела)?

Цитата:

никакой кеш вас не спасёт во время дефрагментации, головки будут постоянно беагать от MFT к файлам

А чем отличается обращение к диску при дефрагментированном и недефрагментированном файле? Не в плане перемещения от фрагмента к фрагменту, а именно в контексте MFT.
Или это из серии "Я придумал что оно делается так, теперь буду доказывать это!".

brRamires

Цитата:

Это легко проверить. Пререзагружаем комп, запускаем Resmon.exe и Диспетчер задач, делаем скриншот, открываем Проводник, лазаем по папкам на всех разделах, делаем второй скриншот. Результат:

И видим только то, что файлокеш увеличился с 212 до 264Мб. Вопрос: а только что загруженная система чего умудрилась накешировать аж на 200 с лишним мегабайт? 9285 вам уже ответил: там MFT С:, плюс во время лазания по разделам фрагменты их MFT добавились.


Цитата:

Кроме того, никакой кеш вас не спасёт во время дефрагментации,

Именно в процессе дефрагментации? Так ее ж если кто и делает, то раз в год... А чаще вообще не делают.


Цитата:

Ничего подобного быть не может.

Вот не надо говорить так категорично: как раз в теории такое запросто может быть.
Цитата:

Зависимость "сантиметры-гигабайты" прекрасно отражает скорость считывания данных. Посмотрите на мой первый скриншот на предыдущей странице: там математически выведенный график совпадает с реальным графиком, полученным программой HDTune.

Ну и причем тут график ПОСЛЕДОВАТЕЛЬНОГО чтения? Ну да, вы посчитали зависимость скорости линейного чтения от радиуса трека, и она совпала с измеренной -- ну так а как это связано с движением голов при случайной записи (вы ведь ее оптимизировать хотите, я так понял?)? Вы на том же скрине посмотрите на чудовищный разброс времени доступа (желтые точки) -- вот реальное отражение перемещений голов, а вовсе не ровный синий график.

9285, dimitriy7

Цитата:

Не возникала мысль о том, что MFT уже закэшированна (на стадии монтирования раздела)?

Цитата:

И видим только то, что файлокеш увеличился с 212 до 264Мб. Вопрос: а только что загруженная система чего умудрилась накешировать аж на 200 с лишним мегабайт? 9285 вам уже ответил: там MFT С:, плюс во время лазания по разделам фрагменты их MFT добавились.

Общий объем MFT на всех разделах у меня порядка 650 Мб. К тому же не известно, что именно там кешируется. Здесь один майкрософтовский эксперт пишет: "MFT кэшируется на равных с другими участками диска". Думаю, ему видней.

Цитата:

А чем отличается обращение к диску при дефрагментированном и недефрагментированном файле? Не в плане перемещения от фрагмента к фрагменту, а именно в контексте MFT.

Речь не о обращении к файлу, а о самом процессе дефрагментации. Если файл находится во второй половине диска, то головкам от MFT до него далеко ездить.

Цитата:

Именно в процессе дефрагментации? Так ее ж если кто и делает, то раз в год... А чаще вообще не делают.

Это у каждого по своему. У меня, например, 2 раза в неделю лёгкая дефрагментация (на месте) и 1 раз в месяц консолидация свободного места.

Цитата:

Ну и причем тут график ПОСЛЕДОВАТЕЛЬНОГО чтения? Ну да, вы посчитали зависимость скорости линейного чтения от радиуса трека, и она совпала с измеренной -- ну так а как это связано с движением голов при случайной записи (вы ведь ее оптимизировать хотите, я так понял?)? Вы на том же скрине посмотрите на чудовищный разброс времени доступа (желтые точки) -- вот реальное отражение перемещений голов, а вовсе не ровный синий график.

Да, разброс времени доступа приличный, но ширина разброса остаётся примерно одинаковой для любого последовательного участка диска. Само же время доступа повышается от начала к концу диска, и если скорость чтения в начале диска в 2 раза больше, чем в конце, то время доступа - в 2 раза ниже, т.е. зависимость остаётся той же.

brRamires

Цитата:

Общий объем MFT на всех разделах у меня порядка 650 Мб. К тому же не известно, что именно там кешируется. Здесь один майкрософтовский эксперт пишет: "MFT кэшируется на равных с другими участками диска". Думаю, ему видней.

Ну еще раз:
Разве где кто писал, что кешируется MFT сразу целиком и всех разделов? Вот сколько у вас весит $MFT раздела С:? в 212 Мб ведь легко влезает? А при доступе к другим разделам кешируется не весь $MFT, а только реально используемые фрагменты -- вы при просмотре папок на них накопили еще 50Мб -- вы знаете, сколько это файловых записей? Порядка 50 тыс., между прочим. Ну а как и что в точности кешируется, да, я не знаю, но на свежезагруженной системе что еще может в кеше оказаться, если вы еще ни с какими файлами работать не начинали?
А по поводу мнения эксперта -- а разве оно где-то противоречит моему или 9285? Нет, не противоречит, наоборот: уже третий человек утверждает: MFT кешируется! Так же, как и другие файлы: когда открывается на ч/з. Т.е. ВСЕГДА В ПЕРВУЮ ОЧЕРЕДЬ и самым агрессивным образом, ибо при первом доступе к разделу $MFT читается первым (после $Boot) и при этом используется чаще других файлов. Ну а если мы с раздела вышли и не трогаем, его MFT, понятно, из памяти выгружается.


Цитата:

Да, разброс времени доступа приличный, но ширина разброса остаётся примерно одинаковой для любого последовательного участка диска.

Вот именно: разброс не просто приличный, он сравним с самОй измеряемой величиной.
Кстати, можете сделать аналогичный тест скорости чтения, но не последовательного, а случайного блоками по 4кб?

brRamires

Цитата:

Если файл находится во второй половине диска, то головкам от MFT до него далеко ездить.

Всё таки я напишу это.
В каждом конкретном случае имеется специфика, которую и нужно учитывать при оптимизации разбиения диска. Но рассматривать в таком ракурсе бесполезно, потому как это 100500 вариантов разбивки.
Поэтому и используется наиболее характерные случаи.
И один из таковых (конечно же ИМХО), стандартная система используемая для работы в интернете, просмотра фоток, видео, прослушивания музыки.
В таком случае обычно интенсивно используется системный раздел (временные файлы, своп, кэши бразеров и т.п.). К данным, как таковым, пользователь обращается нечасто.
В моём представлении диск (не 4 ТБ естественно) видится разделённым на 3 раздела - система в начале, раздел с данными, раздел с всякой редко используемой дребиденью.
Насколько понимаю, в твоём для данных уже два раздела. В таком случае как по ним раскидать инфу - на одном фотки, на другом музыка? И что будет с головками если сначала открывается фото, а потом музыка. И это при том что такие обращения нередки.
А через время один из разделов заполняется больше чем на 88%, и возникает вопрос о перебросках, дефрагментация усложняется и т.п.
И всё это ради (сомнительной) выгоды от перемещения головок?

Как я уже написал овчина не стоит выделки.


Цитата:

Здесь один майкрософтовский эксперт пишет

Когда только увидел эту фразу, почему то представил кого там увижу. И не ошибся.
Из такой же микрософтовский спец как Н. Валуев балерина. Кстати, ему совсем недавно в другом месте, аналогичные же "спецы" (разве что кроме одного) напихали по самые помидоры.
MVP это не атрибут специалиста - в отношении некоторых (особенно ошивающихся на осзоне или микрософтовском форуме) это означает подлизывание микрософта, причём выполняемое с подавлением всех несогласных (на микрософтовском он как раз таки эти пользуется) с идеологией их хозяина.

Поправочка. Среди MVP есть и нормальные люди, для которых важна истина а не амбиции. И среди таковых - mwz. Жаль что таковых малоФато.