Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Операционные системы » Microsoft Windows » Наилучшее разбиение диска на разделы

Модерирует : KLASS, IFkO

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Открыть новую тему     Написать ответ в эту тему

tccb



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Подскажите, как лучше разбить диск на логические диски.
Я для себя сделал С(NTFS)-системный,D(NTFS)-программы,E(FAT32)-всякие разные файлы (фильмы,дистрибутивы).
Может подскажете что получше?

Всего записей: 385 | Зарегистр. 05-02-2002 | Отправлено: 16:35 11-02-2005 | Исправлено: vu1tur, 17:29 01-01-2008
brRamires

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

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

Всего записей: 564 | Зарегистр. 28-09-2008 | Отправлено: 18:30 21-09-2013 | Исправлено: brRamires, 18:31 21-09-2013
dimitriy7



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
brRamires

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

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

Всего записей: 2946 | Зарегистр. 09-10-2008 | Отправлено: 20:35 21-09-2013
9285

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 21:39 21-09-2013
brRamires

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

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

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

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

Всего записей: 564 | Зарегистр. 28-09-2008 | Отправлено: 22:58 21-09-2013
9285

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 01:04 22-09-2013
brRamires

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

Всего записей: 564 | Зарегистр. 28-09-2008 | Отправлено: 09:58 22-09-2013 | Исправлено: brRamires, 10:00 22-09-2013
dimitriy7



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

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

Всего записей: 2946 | Зарегистр. 09-10-2008 | Отправлено: 16:01 22-09-2013
brRamires

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

Это легко проверить. Пререзагружаем комп, запускаем Resmon.exe и Диспетчер задач, делаем скриншот, открываем Проводник, лазаем по папкам на всех разделах, делаем второй скриншот. Результат:
 
Как видно, ни о каких 300 Мб и речи не идёт.
Кроме того, никакой кеш вас не спасёт во время дефрагментации, головки будут постоянно беагать от MFT к файлам, так что это ещё один аргумент в пользу двух разделов против одного.

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

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

Всего записей: 564 | Зарегистр. 28-09-2008 | Отправлено: 17:32 23-09-2013 | Исправлено: brRamires, 17:36 23-09-2013
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
brRamires
Не возникала мысль о том, что MFT уже закэшированна (на стадии монтирования раздела)?

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

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 17:59 23-09-2013
dimitriy7



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
brRamires

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

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

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

Всего записей: 2946 | Зарегистр. 09-10-2008 | Отправлено: 18:47 23-09-2013
brRamires

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
9285, dimitriy7

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


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

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

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

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

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

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

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

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

Всего записей: 564 | Зарегистр. 28-09-2008 | Отправлено: 23:46 23-09-2013
dimitriy7



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
brRamires

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

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

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

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

Всего записей: 2946 | Зарегистр. 09-10-2008 | Отправлено: 01:49 24-09-2013
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
brRamires

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

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

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

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

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 12:34 24-09-2013 | Исправлено: 9285, 14:00 24-09-2013
brRamires

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
dimitriy7
Я и не спорю, что часть MFT кешируется, но при записи этот кеш роли не играет: головки всё равно должны будут съездить к области диска, где MFT расположена.

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

Не знаю программы, умеющей проводить случайное чтение/запись определённой области диска, не выходя за заданную пользователем границу. Намного актуальнее был бы другой тест: сделать на пустом диске один раздел, забить его файлами, фрагментировать их прграммой myfragmenter и замерить время дефрагментации раздела; затем переразбить диск на 2 раздела по описанной мной методике, забить разделы теми же файлами, фрагментировать их и замерить время дефрагментации этих двух разделов. Но для такого теста нужен свободных диск, у меня такого нету...
 
9285

Цитата:
Насколько понимаю, в твоём для данных уже два раздела. В таком случае как по ним раскидать инфу - на одном фотки, на другом музыка? И что будет с головками если  сначала открывается фото, а потом музыка. И это при том что такие обращения нередки.  
А через время один из разделов заполняется больше чем на 88%,  и возникает вопрос о перебросках, дефрагментация усложняется  и т.п.  
И всё это ради (сомнительной) выгоды от перемещения головок?
 
Как я уже написал овчина не стоит выделки.
 
 
Если бы жёсткий диск был организован по принципу флеш-памяти, то никакого смысла создавать на нём больше одного раздела (для данных) не было бы, т.е. сокращение перемещения головок - практически единственная причина для этого; а как будут использоваться эти разделы - тут всех сценариев не предусмотришь.
Насколько это эффективно или нет, пока ещё никто не доказал. Я предложил концепцию, всем желающим предлагаю её проверить в действии.

Всего записей: 564 | Зарегистр. 28-09-2008 | Отправлено: 13:44 25-09-2013 | Исправлено: brRamires, 13:47 25-09-2013
Ahaltek



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
два раздела самый раз. первый только под винду, а второй фильмы музыка документы(папки посоздавать)... в винде можно "Мои док-ты" перенести на второй. Создать "Program files" и позакидывать Portable winamp opera donloadmaster и мого других програм работают без переустановки

Всего записей: 238 | Зарегистр. 08-09-2008 | Отправлено: 16:56 25-09-2013
bomzzz



Запрет на пост
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
время на чтение блоков файла раскиданные по флешке или ссд все равно тратится. нет смысла ложить все яйца в одну корзину

Всего записей: 13343 | Зарегистр. 13-01-2008 | Отправлено: 17:05 25-09-2013
9285

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
brRamires
Ну так по концепции лучше ещё больше разделов сделать - чтобы головки вообще не двигались.
И я так и не услышал ответа на версию что одновременно используется файл с одного и другого раздела. Как быть с головками?
PS. И это  - как то пропустил ты зонное распределение. А ведь там не всё так красиво как в теории.
 
PPS. Уменьшение числа перемещений головок - вещь несомненно неплохая, но лично для меня этот аргумент для разбиения винта на разделы, не самый критичный - скорей всего в коце "очереди".

Всего записей: 4833 | Зарегистр. 06-10-2010 | Отправлено: 03:43 26-09-2013
suomifinland



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ребята, вопрос... Теряется ли место на жестком диске, если он разбит на большое количество разделов. Или что лучше иметь 2-3 раздела на новом диске, или.., 6-9 разделов... Просто вышел спор.., с мужем... ;-(

----------
Мы на горе всем буржуям, мировой пожар раздуем... А.Блок.

Всего записей: 5257 | Зарегистр. 16-04-2006 | Отправлено: 21:46 11-10-2013
dimitriy7



BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
suomifinland

Цитата:
Теряется ли место на жестком диске, если он разбит на большое количество разделов

Не теряется.

Цитата:
Или что лучше иметь 2-3 раздела на новом диске, или.., 6-9 разделов

Как больше нравится, так и делайте. Только делайте их штатными виндовыми средствами (diskpart + format, ну или через графическую морду для них diskmgmt.msc), без применения стороннего глюко-ПО вроде акронисов-парагонов.

Всего записей: 2946 | Зарегистр. 09-10-2008 | Отправлено: 21:57 11-10-2013
suomifinland



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ну вот, а я надумалась Acronis DD делать...  ;-(

----------
Мы на горе всем буржуям, мировой пожар раздуем... А.Блок.

Всего записей: 5257 | Зарегистр. 16-04-2006 | Отправлено: 22:20 11-10-2013
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104

Компьютерный форум Ru.Board » Операционные системы » Microsoft Windows » Наилучшее разбиение диска на разделы


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru