» Долгое копирование с сервера

При попытке юзверя что-то скопировать на сервер или с него копирование и дет долго и натужно. Не пора ли бэкапить винт ? W2k. Другими протоколами не занят.

Dekker
С всех машин копирование с/на сервер идет долго?
А как между клиентами/другими серверами?
Какая сетка, скорость, свитчи/хабы, сетевухи?

Dekker

Цитата:

бэкапить винт

Ты имеешь в виду дефрагентацию диска. У NT3.01 и выше, если не трогать, то и лучше. А если взялся один раз провести дефрагментацию, то после этого нужно постоянно ее проводить. Да и напиши все, что спросил
Crash Master

при обращении даже одной машины к серверу
сеть стоит на оборудовании Surecom
сеть 100mb витуха
между клиентами все нормально

Dekker
А что происходит если копировать файлы не по сети а в пределах сервака ? С консоли ?

Dekker
А какой винт на серваке? И может это вообще сетевуха сервера.

винт простенький WD 60G 5400 ... сетевую посмотрели поменяли тормоза при копировании пропали (просто что-то с контактами карта нормальная) чаще с сервера пыль стирать нада. А вот тормоза при инициализации пользителя остались.

igcomp

Цитата:

У NT3.01 и выше, если не трогать, то и лучше. А если взялся один раз провести дефрагментацию, то после этого нужно постоянно ее проводить.

С чего такие выводы, тезка?

Dekker

Цитата:

А вот тормоза при инициализации пользителя остались.

Ты говоришь о входе в домен?

Crash Master
да, ой как не хочется все переставлять, всего-то восемь машин в сети ... винт откатил на другой, 56Г софта и драйверов пятилетний опыт работы фирмы.

Попробуй замерит скорость пр копировании. Последний FAR показывает. У меня около 7000кб/сек

Настройки сетевухи это
дело не в контактах и пыли

UncoNNecteD
нда ? а почему после тупого перетыкивания разьема все стало нормально (с копированием), электроника наука о контактах это уже аксиома

Цитата:

сетевую посмотрели поменяли

Dekker
Ты ж написал что поменяли...
Пыль контакт в PCI разъеме не нарушит - ну никак...

Цитата:

А вот тормоза при инициализации пользителя остались.

Насколько я понимаю проблема еще осталась , но копирование уже идет нормально .
Какие протоколы живут в сети и какая ось сервера ?
ooptimum

Цитата:

Цитата:У NT3.01 и выше, если не трогать, то и лучше. А если взялся один раз провести дефрагментацию, то после этого нужно постоянно ее проводить.

С чего такие выводы, тезка?

Выводы с известного факта , что при дефрагментации средствами winnt , она не пишет более одного файлы в кластер и каждый файл начинает с нового кластера . Соответственно если после дефрагментации писать на диск информацию она оказывает побита на Мноооого маленьких кусочков ибо пишется с начала диска.
Большинство имеющихся программ дефрагментации использую windows API и на выходе тот-же результат .
Нормально дефрагментируют Norton и deerfield (в последнем не уверен).
Я возможно чуть исказил информацию , но смысл такой - файлы при дефрагментации пишутся начиная с нового кластера и диск становится похож на решето .

Zlobny_John
Мда... С какого вдруг бодуна в 1 кластере, судя по твоим словам, может быть более 1 файла? Ты жестоко заблуждаешься, коллега. IMHO ты, как говорится, слышал звон... В NTFS действительно присутствует проблема при записи/удалении большого числа маленьких файлов. Но эта проблема связана не с кластерами, а с MFT. И лечится она либо форматированием, либо дефрагментацией. Я пользую Diskeeper -- лучшее, что есть под винды, IMO. Но тот тезис, что надо либо не оптимизировать вообще, либо постоянно -- полная чушь. Надо по мере надобности. (с) Я

[добавлено позже]Слово кластер в компьютерной тематике имеет значение как группа, пакет, блок . И совсем не обязательно этот кластер обьединяет секторы .
Помоему правомерно назвать кластером неизвестное постоянное количество кластеров файловой системы NTFS.
[добавлено позже]
Итого .
слово кластер в предидущем сообщении меняем на 16 кластеров .
читаем дальнейший ликбез

--------------------------------------------------------------------

В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:

В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости).
Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) "временно занятое место", дополняющее его по размеру до кратности 16 кластерам.
При попытке как-то неправильно ("не кратно 16") переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается… Тем не менее, всё место действия щедро рассыпается "временно занятым местом".
"Временно занятое место" служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты.

Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке):

Вынимание файлов из MFT зоны. Не специально - просто обратно туда их положить не представляется возможным Безобидная фаза, и даже в чем то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе - при перезагрузке, отдельным процессом, как в старом Diskeeper-е.
Складывание файлов ближе к началу - так называемая дефрагментация свободного места. Вот это - воистину страшный процесс...
Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.

Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.

Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую - Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.

К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) - так сразу надо качать Speeddisk для W2k.

Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически.

----------------------------------------------------------------------------

таким образом

Цитата:

Я пользую Diskeeper -- лучшее, что есть под винды, IMO. Но тот тезис, что надо либо не оптимизировать вообще, либо постоянно -- полная чушь. Надо по мере надобности. (с) Я

это только твоё IMO и O неправильное.
Ибо


Цитата:

Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.

Цитата:

Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.

Цитата:

Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую - Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия.

Добавлено
http://www.ixbt.com/storage/ntfs.html

Zlobny_John
Молодец Джон. Мне просто лень столько писать.

igcomp
Ну, он не сам писал. Он просто скопировал.

Цитата:

Мне просто лень столько писать

Я сомневаюсь, что ты можешь столько написать про NTFS сам, даже если захочешь и тебе будет не лень.

Zlobny_John

Цитата:

Слово кластер в компьютерной тематике имеет значение как группа, пакет, блок. И совсем не обязательно этот кластер обьединяет секторы. Помоему правомерно назвать кластером неизвестное постоянное количество кластеров файловой системы NTFS.

Это софизм, коллега. Т.е., говоря научным языком, -- "особый прием интеллектуального мошенничества, попытка выдать ложь за истину и тем самым ввести в заблуждение". Применительно к NTFS кластер -- это все-таки набор секторов и он фиксированного размера. Ведь мы говорим про NTFS? И поэтому, ты, как по-моему здравомыслящий человек, понимаешь, что твое "помоему" как минимум очень натянуто, а на самом деле просто ложно. Для того, чтобы не выглядеть упертым, я навскидку взял отсюда первое попавшееся мне определение кластера: кластер - минимальный размер места на диске, которое может быть выделено файловой системой для хранения одного файла. ... Хотя я по-человечески понимаю, почему ты написал свою приписку.

Теперь давай разберемся с тем, что ты скопировал.


Цитата:

В NT существует стандартное API дефрагментации.

Фирма Executive Software была вообще первой, которая выпустила дефрагментатор для NTFS еще во времена NT 3.51. Потом, в NT 4, M$ по запросу этой фирмы внесла дополнительную функциональность для перемещения кластеров в драйвера NTFS и FAT. Как раз вот это самое API. А это говорит само за себя.


Цитата:

Вынимание файлов из MFT зоны. Не специально - просто обратно туда их положить не представляется возможным

Да, специально их туда положить невозможно. Но вот файлы небольшого размера размещаются непосредственно в записи MFT, описывающей этот файл, для сокращения времени доступа. (Помнишь, я писал
Цитата:

В NTFS действительно присутствует проблема при записи/удалении большого числа маленьких файлов. Но эта проблема связана не с кластерами, а с MFT.

?)
Соответственно, если размер файла не изменялся и он каким-то образом был "вынут из MFT зоны", а этого, как я понимаю, можно добиться только его удалением/перемещением на другой диск и никак иначе, то при попадании обратно на исходный диск он попадет опять в MFT. Более того, с помощью вышеупомянутого API нельзя дефрагментировать MFT. Поэтому не совсем понятно, зачем вообще было написано про "внимание-вынимание" (С этой фразы начинаются трансляции Армянского Радио ).

Хмм...
Цитата:

Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000

Очень не уверен. Откуда такая информация? Официальный источник? (я просто еще и программист системный, ну хобби у меня такое, вот и интересуюсь)


Цитата:

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

Этим грешит именно Speed Disk в наибольшей мере (из тех, которые я знаю). Хотя это не такая уж и проблема. Если файлы на диске меняются не часто, то такое поведение очень оправдано.

Далее идет какой-то, IMNSHO, бред по поводу дырок и "проблемы" 16 кластеров. Если ты программист, то можешь почитать описание функции NtFsControlFile в части FSCTL_MOVE_FILE. Да, при перемещении файла позиция внутри перемещаемого файла (StartVCN) должна быть кратна 16 кластерам, но то место на диске, куда перемещается файл (TargetLcn) не имеет никаких ограничений. Это принципиальное земечание, которое очень важно понимать правильно. Из него следует, что при перемещении файлов средствами API не будут образовываться никакие "дырки", т.к. ничто не мешает располагать файлы на диске "впритык" друг к другу. Здесь ты положился на авторитет iXBT, но как известно, никто не идеален и они тоже могут ошибаться.

Далее про файлы, "плавно созданный на прооптимизированном диске". А также про
Цитата:

Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие

из оригинальной статьи с iXBT. Насколько мне не изменяет мой склероз, политика размещения файлов на диске настраиваема. Для этого есть параметр в реестре. Хотя, к сожалению, эта политика относится к системе в целом, а не к отдельным дискам. Но это уже не в кассу...

Давай теперь разберем следующие 2 фрагмента из данной статьи.

Цитата:

Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске

и

Цитата:

Фрагментация NTFS через пол года работы доведет до искреннего удивления любого человека, знакомого с работой файловой системой.

Так что все-таки лучше, смириться и изумляться через пол-года или все-таки дефрагментировать? Я дефрагментирую. Об этом и писал. Ни твое сообщение, ни цитированная статья не убеждают меня в обратном. Более того, тезис про 1 кластер, 1 файл и твои заблуждения, так по-видимому задевший тебя, так и не опровергнут. ... Я бы еще подискутировал, но мне лениво. И так все ясно, на мой взгляд.

Теперь почему я предпочитаю Diskeeper. Во-первых, он дастаточно быстр и вполне надежен. Во-вторых, мне удобно им пользоваться в локалке. А в-третьих, для некоторых репутация важнее многих других вещей (помнишь про API дефрагментации и тесные связи между M$ и Executive Software?).

Я не пользуюсь SpeedDisk'ом уже давно, ибо те версии, которые я использовал (5 и из состава NU для NT) были еще те тормоза. К тому же меня смущает то, что они явно пользуются какими-то неизвестными "хакерскими" методами, чего я не приемлю в тех случаях, когда данные дороже всех моих серверов, вместе взятых. Вы же вольны пользоваться чем угодно. Чао вашей машине...

Добрый день,

Я автор этой статьи.
Хочу сказать, что прошло 3 года, и она конечно немножко устарела. Тем не менее кратко скажу (скажу еще сразу, что не смогу учавствовать в дискуссии):

1. Я более-менее поддерживаю ooptimum по всем пунктам.

2. Diskeeper действительно лучше всех по сумме баллов. Speeddisk действительно хакерствует и сбоит.

3. Всё таки поведение касательно 16 кластеров мной описано правильно, просто надо читать всю статью. Это не только и не столько ограничение API дефрагментации, сколько поведение самой системы в этом процессе, не имеющее отношения к API.

4. По большому счету в Windows 2000 и Windows XP, если грамотно работать с API, ограничений никаих вообще нет.

Спасибо за интерес к статье; добавлю еще раз - она старая и в существующих обстоятельствах (3 года прошло) уже не очень точна. Обновляться не будет.