Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
венда понимает только дефолтный размер кластера. 28.11.07 10:31 Число просмотров: 3175
Автор: jammer <alex naumov> Статус: Elderman
|
> А если не секрет, зачем понадобился другой размер кластера?
как обычно - либо место съэкономить, либо ФС убыстрить.
я тоже в свое время экспериментировал в сторону увеличения кластера для разделов под видео/мп3 - но ввиду того что винда не умеет даже дефрагментировать (а то и чекать) такие волумы, бросил это занятие.
я так понимаю, в винде много чего такого якобы сделано, а на самом деле не работает, так и выбор размера кластера в том числе.
|
|
<operating systems>
|
[NT] Установка ХР на раздел NTFS с недефлотовым размером кластера. 27.11.07 13:19
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Или как это размер кластера системного раздела потом изменить?
Пробовал заниматься такой ерундой - ничего не вышло. Если раздел заблаговременно отформатирован, а при установке выбирается последний пункт из списка:
1. Быстрое форматирование ФАТ
2. Быстрое форматирование НТФС
3. Медленное форматирование ФАТ
4. Медленное форматирование НТФС
5. Оставить ФС без изменения, не форматировать, ставить на ту ФС, какая есть.
При первой же перезагрузке выдается сообщение что-то типа диск еррор или бут еррор.
С пунктами 1 или 2 все проходит нормально.
Может при установке нужно что-то нажать?
Кто-нибудь решал эту проблему? Поделитесь опытом или соображениями.
|
|
Возможно загрузчик понимает только дефолтный размер кластера. 27.11.07 16:58
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
|
А если не секрет, зачем понадобился другой размер кластера?
|
| |
венда понимает только дефолтный размер кластера. 28.11.07 10:31
Автор: jammer <alex naumov> Статус: Elderman
|
> А если не секрет, зачем понадобился другой размер кластера?
как обычно - либо место съэкономить, либо ФС убыстрить.
я тоже в свое время экспериментировал в сторону увеличения кластера для разделов под видео/мп3 - но ввиду того что винда не умеет даже дефрагментировать (а то и чекать) такие волумы, бросил это занятие.
я так понимаю, в винде много чего такого якобы сделано, а на самом деле не работает, так и выбор размера кластера в том числе.
|
| | |
Не получилось вчера. Может сегодня попробую - напишу... 28.11.07 10:40
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> как обычно - либо место съэкономить, либо ФС убыстрить.
Не получилось вчера. Может сегодня попробую - напишу. Сдается мне, что не в размере кластера тут дело.
> я тоже в свое время экспериментировал в сторону увеличения
> кластера для разделов под видео/мп3 - но ввиду того что
> винда не умеет даже дефрагментировать (а то и чекать) такие
> волумы, бросил это занятие.
Дефрагментация помогала в старом добром ДОСе, поэтому и програмы там были.
В нормальных операционках дефрагментация не играет большой роли в производительности. Если на диске будет полная каша, то это повлияет только на первый запрос на чтение. После того, как все осядет в кеши, степень фрагментации и размер ReadAhead роли уже играть не будут никакой. Поэтому в винде нет хороших дефрагментаторов. С чеканием в винде все нормально, никаких проблем я не замечал.
> я так понимаю, в винде много чего такого якобы сделано, а
> на самом деле не работает, так и выбор размера кластера в
> том числе.
А вот это очень интересный и даже проазительный момент.
|
| | | |
правда чтоли? то есть кеш в памяти бесконечный и сики по... 28.11.07 15:40
Автор: jammer <alex naumov> Статус: Elderman
|
> Дефрагментация помогала в старом добром ДОСе, поэтому и
> програмы там были.
> В нормальных операционках дефрагментация не играет большой
> роли в производительности. Если на диске будет полная каша,
> то это повлияет только на первый запрос на чтение. После
> того, как все осядет в кеши, степень фрагментации и размер
> ReadAhead роли уже играть не будут никакой. Поэтому в винде
> нет хороших дефрагментаторов. С чеканием в винде все
> нормально, никаких проблем я не замечал.
правда чтоли? то есть кеш в памяти бесконечный и сики по современным хардам стали как на флешках - нулевыми? ну спасибо! успокоил! =)
> > я так понимаю, в винде много чего такого якобы сделано, а
> > на самом деле не работает, так и выбор размера кластера в
> > том числе.
> А вот это очень интересный и даже проазительный момент.
насколько я знаю венду, всему плохому, с ней связанному, удивляться не приходится. проблема бывает только с предсказанием, какое именно говно случится, но то, что оно обязательно будет, неминуемо.
|
| | | | |
Зачем бесконечный, не, бесконечный не нужен. Для того, чтоб... 29.11.07 12:21
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> правда чтоли? то есть кеш в памяти бесконечный и сики по
> современным хардам стали как на флешках - нулевыми? ну
> спасибо! успокоил! =)
Зачем бесконечный, не, бесконечный не нужен. Для того, чтоб в процессе работы не было задержен на обращение к диску, нужно лишь чтоб емкость свободной оперативки была эквивалентна размеру всех файлов, задействованых при работе.
Вот на примере. Файловый сервак с двумя гигами оперативки. Допустим операционка занимает почти гиг. Куча рабочих станций интенсивно работают всего с одним файлом (допустим это база какая-нибудь). Если размер этого файла в пределах гига, то в процессе работы не будет прочитано с диска более гига (все работают только с одним файлом), потому что он весь закешируется. Если размер этого файла превышает гиг (а тем более, если превышает общий объем оперативки), то при интенсивной работе со всем файлом будет происходить периодическое подчитывание с диска тех данных, которые на сохранились в кеше. Эти свежесчитанные данные будут осядать в кеше вытесняя другие.
Я этих экспериментов уже столько поставил. Вот сейчас зашел в каталог, где файлов чуть меньше, чем оперативки, набрал "copy /b.nul". ~12 секунд считывалось. Повторно около 1 секунды считывалось, лампочка активности винта не загоралась. С каталогом, где объем файлов превышал объем оперативки, такого не получилось.
> насколько я знаю венду, всему плохому, с ней связанному,
> удивляться не приходится. проблема бывает только с
> предсказанием, какое именно говно случится, но то, что оно
> обязательно будет, неминуемо.
Вчера продолжит экспериментировать. Обнаружено, что командой format можно форматить с размером кластера от 512 до 64к (и более, если размер сектора более 512). Графическая оболочка предлагает выбрать размер кластера из списка 512, 1024, 2048 и 4096. Какой смысл скрывается под словом "Стандартный" пока непонятно. Форматнул раздел из командной строки с размером кластера 4096. Результат - винда поставилась на существующий формат. К сведению, после форматирования с размером кластера 32к и 16к проверял структуру чекдиском, все нормально форматировано. Было предположение, что разные форматировщики по разному инициализируют бутсектор раздела, а инсталятор не трогает бутсектор, если только не сам форматирует раздел. Причем в последнем случае прописывает туда правильный буттер. Все не так, поскольку винда встала на существующий формат. Не экспериментировал только с размеров 8192 и менее 4096 (2048, 1024, 512). Уже не хочется рерять время, но полагаю, что на 8к не встанет, а на 2к, 1к, 0.5к встанет.
|
| | | | | |
это нереально. у меня на файлсервере щас больше 2 Тб. из них... 05.12.07 15:14
Автор: jammer <alex naumov> Статус: Elderman
|
> нужно лишь чтоб емкость свободной оперативки была
> эквивалентна размеру всех файлов, задействованых при работе.
это нереально. у меня на файлсервере щас больше 2 Тб. из них юзается не меньше четверти.
> Вот на примере. Файловый сервак с двумя гигами оперативки.
> Допустим операционка занимает почти гиг. Куча рабочих
> станций интенсивно работают всего с одним файлом (допустим
не бывает. только если 1С или типа того поделка.
> периодическое подчитывание с диска тех данных, которые на
> сохранились в кеше. Эти свежесчитанные данные будут осядать
> в кеше вытесняя другие.
спасибо, просветил ;))
> Я этих экспериментов уже столько поставил. Вот сейчас зашел
> в каталог, где файлов чуть меньше, чем оперативки, набрал
> "copy /b.nul". ~12 секунд считывалось. Повторно около 1
> секунды считывалось, лампочка активности винта не
> загоралась. С каталогом, где объем файлов превышал объем
> оперативки, такого не получилось.
а на кеше размером в 8М дум2 (размером в 16М) весь кешировать никогда не удавалось? а мне удавалось. это чтобы ты опять не объяснял как работает кеш.
> (2048, 1024, 512). Уже не хочется рерять время, но полагаю,
> что на 8к не встанет, а на 2к, 1к, 0.5к встанет.
вот такая поделка кривая - частично совместимая сама с собой. и так везде.
|
| | | | | | |
Значит все данные никогда в памяти не осядут и от обращений... 05.12.07 19:22
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 05.12.07 19:26 Количество правок: 2
|
> это нереально. у меня на файлсервере щас больше 2 Тб. из
> них юзается не меньше четверти.
Значит все данные никогда в памяти не осядут и от обращений к диску в процессе работы в вашем случае не избавиться.
> не бывает. только если 1С или типа того поделка.
Еще я сам смогу взять сервак с двумя гигами оперативки, залить туда гиговый файл, скачивать его с разных станций и смотреть как моргает лампочка активности диска и моргает ли вообще, а так же измерять скорость первого считывания и последующих.
> а на кеше размером в 8М дум2 (размером в 16М) весь
> кешировать никогда не удавалось? а мне удавалось. это чтобы
> ты опять не объяснял как работает кеш.
Прочитал еще раз всю ветку, думал, что где-то ошибся. Нет, все верно. Если оперативки хватает, чтоб файлы закешировались, то к диску обращений не будет. Если все файлы закешируются, то их фрагментация на диске не влияет на скорость работы с этими файлами. Я так и не понял какое из утверждений вы ставите под сомнение? Вот еще несколько утверждений: Если файлы должны закешироваться (оперативки хватает для этого), но в процессе работы с ними на счтывание обращение к диску все же происходит, значит такая поганая система кеширования. Если в процессе работы происходит запись в файлы, то интенсивность обращения к диску зависит от настройки задержки слива на диск "грязного" кеша. Если для полного кеширования оперативки немного нехватает, то будут незначительные обращения к диску, а влияние фрагментации на быстродействие будет минимально. Если оперативки ничтожно мало, то обращения к диску будут значительны и влияние фрагментированости файлов на производительность будет максимально.
|
| |
С этим я боролся на своем НБ дома в течение 6-8 часов,... 27.11.07 18:13
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 27.11.07 18:14 Количество правок: 1
|
> А если не секрет, зачем понадобился другой размер кластера?
С этим я боролся на своем НБ дома в течение 6-8 часов, просто долго идет процесс первоначального копирования файлов с СиДи на винт. Пробовал хоть чем-то форматать, а именно, загрузившись с ЛивСиДи (типа реаниматора), в котором почему-то не работает панель управления дисками, пишет RPC-Server не доступен, хотя все нормально.
Ситуация очень глупая - имеем свежеотформатированый винт и возможность в сетапе устанавливать на существующий формат. Хотя, с точки зрения Микрософта, может быть вполне нормальная, а не глупая.
Так вот сначала я тоже так подумал, что это их баги. Загрузчик, не определяет реальный размер кластера, а считает его по дефолту. Единственное, что я не попробовал, это форматнуть дефолтным размером или явно указав размер, который должен быть дефолтным. Теперь меня терзают смутные сомнения. Может не загрузчик виноват, а инсталятор.
Ну и зачем понадобился. Нужды особой совершенно нет. Просто хотелось плюнуть на мертвое пространство в пользу производительности, которая может увеличиться хотя бы из-за уменьшевшейся фрагментации. А когда эта элементарная прихоть не получилась, вот тут и заело "должен же быть какой-то способ".
Для чистоты эксперимента попробую вечерком то, что не пробовал.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
