Админ говорит что на SSD пошли беды, по причине того что на ней 2003 сервак стоит. Поискал в нете, никаких особых историй про это нет, может ли 2003 сервак, являться причиной бедов на SSD?

беда...

конечно

(0)*bed блоки конечно

(2) По причине?

не bad'ы, а read-only ячейки наверное (ну суть одна)

кроме системы что еще на SSD находится?

опять беда...

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

(5) система на обычном, там только база

сначала написал "на SSD пошли беды, по причине того что на ней 2003 сервак стоит", теперь - уже другое

автор, у вас раздвоение какое-то

(9) да типичная шизофрения, более корректно будет сказать, под управлением 2003 сервака, да?

(0) А тебе зачем наши советы? Пускай админ сам и рулит.

вообщще - поставьте 2012 и не включайте ...

а вообще все беды от кривых рук

up

(0) да

http://bit.ly/16dcvt4

ХР и 2003 соответственно не оптимизированы для SSD.
Операционка может использовать одну ячейку для записи, а не равномерно расходовать ресурсы винчестера.

(18) Спасибо

А если отвести на SSD треть от общего пространства, например 90 гигов от 256 - насколько хватит подобного диска под Win2003? Вроде бы контроллер диска должен уметь самостоятельно подменять умершие ячейки?

(20) У меня так админ сделал. Как раз по этой причине вроде.

(21) сколько уже проработал SSD?

(8) Сделай бэкап, пока не похерилось все

(22) Хз, три месяца всего работаем так.

(18)Бред
(0)2003 server так же как и win XP никак не оптимизированы под SSD, поэтому SSD подвергается некоторым излишним нагрузкам.
Однако так вот сказать что 2003 server убивает SSD диски нельзя.
На самом деле ничего плохого он не делает.
В том что пошли бэды виноват либо производитель(брак), либо жесткие условия эксплуатации.
Отуствтвие трима в 2003 сервере диск никак не убъет, просто упадет быстродействие, и  увеличится неравномерность износа.
Однако достаточно просто оставить процентов 30диска неотформатированным, и отсутствие трима будет практически незаметно.
Короче не забивайте диск под завязку и будет вам счастье.

(25) Объясни плиз, почему если часть диска неотформатировать, проблемы не будет? Админ мне это не смог нормально объяснить.

(26)
Если при форматировании ты разметишь не весь диск, то на неразмеченную часть диска ОС ничего не сможет записать, и у контроллера SSD будет достаточно свободных ячеек для равномерного выравнивания, и быстрой записи.

Эта мера эффективна даже при наличии TRIM, а уж при ее отсутствии просто необходима.

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


Поэтому если есть трим - как минимум не забивайте диск под завязку.
Если трима нет, обязательно оставьте часть диска неразмеченной.

Или тебе развернутый ответ нужен?

(20)Контроллер умеет подменять сдохшие ячейки, собственно он этим постоянно и занимается, даже если ячейки не сдохли.
Однако отводят резерв немного не для того чтобы контроллер менял умершие ячейки.

(29) Мне не понятно как он подменяет сдохшие ячейки? Он же их должен подменять из какого-то скрытого резерва, а не за счет свободного места на носителе. Иначе вдруг внезапно пользователь захочет запилить еще один диск из не размеченой области а там контроллер уже занял кучу ячеек под ремапы и что получится? При форматировании вылезет ошибка?

(28) ну я примерно понял, а причем тут 2003 тогда?

(31)2003 не поддерживает трим, как и ХР.
Т.е получается ты удаляешь файлы, а на диске они остаются и диск постепенно забивается под завязку.
Т.е ОС удалила файлы, а контроллер SSD ничего об этом не знает и хранит их. Диск постепенно забивается.

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

(32)  Ерунда полная, команда TRIM нужна для сборщика мусора контроллера SSD, даже без трима он будет работать под разными осями совершенно адекватно, а не забьеьтся под завязку после удаления файлов.

(33)Забьется.
Собственно из за этого и падает производительность без трима.
Диск постоянно забит практически под завязку.
Т.е ОС видит что на диске дофига пустого места, а на самом деле он заполнен информацией.
И удаление происходит не в фоновом режиме, а только при попытке винды записать в уже записанный блок, тогда контроллер понимает, что данные не нужны и освобождает его.
Трим и сборщик мусора совершенно разные вещи.
Трим - команда ОС которая сообщает контроллеру, что некоторые данные можно стереть.
А сборщик мусора - это утилита контроллера которая занимается подготовкой ячеек к записи.

Причина историческая - обычному HDD не нужно стирать информацию перед записью, поэтому и не было предусмотрено команд для стирания типа "трим".
В итоге обычный HDD поработавший некоторое время на компьютере забит информацией на 100%.
Так же обстоит дело и с SSD при отсутствии трима.

Разница лишь в том, что HDD при этом себя нормально чувствует, для него это несущественно.
А вот SSD забитый под завязку работает неэффективно.

(34) Трим это не команда ОС, а команда ATA. Ее может подать не ОС, а любая программа, у интелей кстати в комплекте с ихнеми ССД-хами идет такая прога, которая триммизацию делает даже под XP.
Трим нужен для уборщика мусора контроллера, иначе перезапись нетриммизированных ячеек будет более долгой, чем триммизированных - вот и все, на объем свободного места трим никак не влияет. Почитайте вику или еще где - полно статей по этому поводу.

(36)Абсолютно неверно.
Давай разберемся -
Вся информация о файлах и их нужности содержится только в одном месте - в файловой системе.
Файловая система в современных компьютерах это как правило часть операционной системы.
Именно файловая система подает команды физическим устройствам хранения.
АТА это всего лишь стандарт общения файловой системы и физического устройства хранения.

Теоретически конечно любую АТА команду может подать любая программа или устройство. Только вот какой в этом смысл?
Ну допустим некоторая прога умеет подавать АТА команду диску, как она подаст "трим" ?
Откуда она узнает что данные можно стирать? Эту информацию можно получить только из файловой системы.

Трим  уборщику мусора не нужен.
Уборщик мусора убирает мусор сам, без всякой помощи.
Трим лишь указывает что конкретные данные являются мусором, т.е подкидывает работы уборщику.

(37) По поводу откуда он узнает: http://koitsu.wordpress.com/2013/02/12/how-intels-ssd-toolbox-optimizer-trim-feature-works/

(39)Ты сам то внимательно читал эту статью? Статья грамотная.
Там как раз объясняется популярно, что данные о удаленных файлах кроме как из файловой системы больше не откуда не получить.

А суть оптимизации интела заключается в концепции разреженных файлов (sparse file).
Пример разреженного файла в быту это образ виртуальной машины - нажали кнопку и фактически сразу у нас на диске появился файл размером 100гигабайт. Т.е на самом деле этот файл никто на диск не записывал, и нулями не заполнял, файловая система просто выделила место под него. Кстати не все файловые системы поддерживают эти файлы.

Так вот суть оптимизации - интеловская утилита начинает массово создавать на диске sparse файлы огромного объема.
На диск они не записываются, однако ФС приходится резервировать под них место. Т.е эта утилита вынуждает ФС обратится к диску и зарезервировать место под файл. Вот тут то контроллер SSD и понимает что все это зарезервированное место надо освободить. А поскольку это sparse файл, то реальной записи нет.
В итоге с помощью таких костылей приходится утилита сообщает диску о том какую информацию можно удалить.
И заметь сообщает не напрямую. Она лишь заставляет ФС сделать это.

Ну и естественно сработает такая фишка только на файловой системе которая поддерживает разреженные файлы.
Если ФС их не поддерживает она просто тупо создаст реальный файл забитый нулями и реально запишет его на диск, т.е для ссд это будет очень плачевно.

(40) ФС там непричем! ФС с этими фантомными файлами используется лишь для того, что бы получить номера блоков, которые надо затримить. Далее утилита (через драйвер контроллера) передает контроллеру команду TRIM с номерами блоков:
the Optimizer does after allocating all these sparse files is to calculate the linear LBA ranges which those sparse files actually make up, then proceed to issue the raw DATA SET MANAGEMENT command to the controller for said LBA ranges, which in turn make it to the SSD.
По поводу того что не все ФС поддерживают создание спарж-файлов - ну а кому-то нужна FAT или FAT-32 на SSD?

А по большому счету - пофиг какой файл