PDA

Показать полную графическую версию : [решено] Слетела файловая система


Страниц : 1 [2]

9285_20
28-02-2013, 03:34
Предложить ему это сделать перед изменениями никак?

Tau_0
28-02-2013, 03:38
Предложить ему это сделать перед изменениями никак? »
Ну вот Вы и предложили...:)

ЗЫ Я тоже порой предпочитаю строго как унтер информацию из BPB брать...
DMDE конечно замечательный редактор, но так оно строже , будет...

deniskx
28-02-2013, 03:44
lba_206848_50.bin http://yadi.sk/d/f5fq-wSo2wZqn

lba_117227500_50.bin http://yadi.sk/d/q-cS6juD2wZrD

У меня есть предположение почему так могло случится. Дело в том, что я несколько раз делал/восстанавливал полную RAW копию всего диска SSD 60 Гб прогой HDDRAWCopyTool. Чтобы забэкапить полностью Windows и поставить Linux, а через какое-то время делал копию Linux и восстанавливал Windows. Со всеми потрохами (чтобы с разделами, загрузчиками, правами не было проблем и они полностью скопировались). Так как SSD винт у меня только один, а хотелось бы чтобы оси стояли на быстром винте. Этот слепок в виде 60 Гб img файла я сохранял на 1 Тб винте, а потом сжимал WinRAR-ом к слову. Так вот если у SSD диска уменьшились сектора, например в следствии их износа, не знаю возможно ли такое, а в накатываемой копии секторов было соответственно немного больше, отсюда несоответствие.
Однако SMART показывает, что с диском все в порядке
http://savepic.ru/4131864m.png (http://savepic.ru/4131864.htm)

Tau_0
28-02-2013, 04:58
lba_206848_50.bin http://yadi.sk/d/f5fq-wSo2wZqn
lba_117227500_50.bin http://yadi.sk/d/q-cS6juD2wZrD »
Смотрим загрузочный сектор тома NTFS (самый первый сектор из файла lba_206848_50.bin)
Редактор ===> Загрузочный сектор
и видим такую картинку
http://img534.imageshack.us/img534/2416/ntfs.png

На основании Total NTFS sectors и начала раздела находим его правильный конец таким вот образом: ---

Total NTFS sectors = 117020671
StartLBA = 206848
Тогда
EndLBA = StartLBA + Total sectors = 206848 + 117020671 = 117227519 --- этот конец верный...

Дополнительно убеждаемся в его корректности --- в секторе 117227519 действительно лежит верная копия бута.
http://img706.imageshack.us/img706/9287/ntfsc.png
Не получилось у меня в DMDE шаблон на копию бут сектора тома одеть...???..., --- через WunHex только вышло...

Теперь можно либо таблицу разделов подправить (на мой взгляд это правильнее и строже...), либо (что быстрее и проще) удалить раздел $Nonamt 02, а затем оять его вставить. DMDE должен правильное значение вставить.

Не могу картинку по правке PT показать --- нужен всего лишь один сектор LBA = 0. А у меня его нет, не запросил.:( Пришлите его, или через удаление-вствку корректуру выполните...

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

deniskx
28-02-2013, 05:24
Пришлите его »
lba_0_100.bin http://yadi.sk/d/UqTCP64S2w_nV
Скорее всего просто в результате работы втёмную с различными утилитами так получилось... »
Утилита одна и та же всегда использовалась HDDRAWCopy Tool. Может быть и не в этом дело. Я не припомню, чтобы количество секторов в ней отличалось.

deniskx
28-02-2013, 07:10
удалить раздел $Nonamt 02, а затем оять его вставить. DMDE должен правильное значение вставить. »
Сделал. Теперь Dmde не ругается
http://savepic.ru/4189212m.png (http://savepic.ru/4189212.htm)
Gparted тоже стал нормально отображать разделы. А HDD Doctor ругается на все. И что размеры не совпадают и что в конце есть еще раздел. Наверное не стоит ее слушать.

У меня завалялся августовский архив SSD диска. Подсунул его в HDDRAWCopy Tool и там размеры с текущим диском совпадают. Вот что прога написала:
Source RAW File LBA 117,231,408
Destination SSD LBA 117,231,408

Tau_0
28-02-2013, 09:20
Вот что прога написала:
Source RAW File LBA 117,231,408
Destination SSD LBA 117,231,408 »
Похоже, что Вы правы, --- со временем SSD усыхает...:(
Во дела...:gigi::gigi::gigi:

Поискал навскидку в сети...
Емкость SSD со временем уменьшается?
http://otvet.mail.ru/question/68627926

Добавлено....

Ну вот так можно было скорректировать таблицу разделов

http://img507.imageshack.us/img507/3104/mbr.png
1. Выбрать нужный диск
2. Редактор ====> Таблица разделов
a). Выделяем вторую строку
b). Ctr + E
b). Корректируем поле Число секторов

117033525 <===== 117020671

c). По Ctr + W сохраняем изменения и перезагружаемся...

deniskx
28-02-2013, 10:03
Похоже, что Вы правы, --- со временем SSD усыхает »
Ну емкость то не меняется. Быстродействие должно ухудшаться.

Tau_0
28-02-2013, 10:31
Ну емкость то не меняется. »
А вот это надо и уточнить. Вроде как уменьшается ёмкость на запись, тогда от того, что данные читаются радость невелика...

ЗЫ У меня нет SSD, --- боюсь их..., как та бабушка, которая боялась электричества...

deniskx
28-02-2013, 11:07
У меня нет SSD, --- боюсь их »
Не бойтесь :gigi: . Я пользуюсь уже долго никаких нареканий. С таким настроем нужно боятся и обычных HDD там тоже есть чему сдохнуть.
Емкость уменьшаться не должна. Вот что я нагуглил
http://www.compress.ru/article.aspx?id=21619&iid=987
Также отметим, что если при записи в какойто блок памяти выдается ошибка, то он помечается как Bad-блок и в дальнейшем не используется. Причем объем доступного для записи места при этом не уменьшается, поскольку все Bad-блоки автоматически помечаются как резервные. То есть, если по мере эксплуатации SSD-диска в нем увеличивается количество Bad-блоков, это автоматически означает, что уменьшается размер резервной области диска. Естественно, это приводит к тому, что производительность диска в операциях записи начинает снижаться, поскольку от количества резервных блоков зависит скорость записи.

misha2
28-02-2013, 16:37
Емкость уменьшаться не должна. »
Согласен. Причём ёмкость резеврвной области у ССД больше чем у ХДД в процентном соотношении к рабочему обьёму.




© OSzone.net 2001-2012