Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: Пред. 1 2 3 4 След.
RSS
фс мечты
 
Цитата
buggzy пишет:
у меня вчера вин2к на нтфс грузиться не стала из-за сбоя в файловой системе. загрузился с компашки, фс вылечил - теперь все ок. причем я работу системы обычно завершаю корректно. может, винт сыпется, а я из-за всяких там смартов и не знаю об этом? :(
Загрузи досовский scandisk. Он показывает бэд блоки, если даже они "замещены" резервными. Не на всех файловых системах, конечно :) Еще это умеет делать NDD (Norton Disk Destroyer) под винды из пакета NU.
 
> Загрузи досовский scandisk. Он показывает бэд блоки, если даже они "замещены" резервными.

интересно, как запустить досовский скандиск на ntfs? и еще - скандиск давно научился работать со smart? ;)
 
Цитата
buggzy пишет:
>
свободные блоки - двухсторонний связанный список. занятые блоки указывают на предыдущих и последующий свободные блоки. да, служебной информации будет побольше, чем в традиционных фс, но только для сильно фрагментированных файлов.
хорошо ты все-таки ввел понятие блока. чем он отличается от сектора ? ты же вроде хотел побайтовые потоки организовать... хотя без разбиение информации на блоки не обойтись, железо же работает наиболее эффективно именно с блоками.

Цитата
buggzy пишет:

> проблема записи большого блока данных (свободное место есть но нет такого длинного свободного куска)

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

Цитата
buggzy пишет:

> да кстати, операция записи кроме простого "добавления записи в журнал транзакций" должна включать проверку того, а правильно ли оно записалось

не должна. нижний уровень будет обеспечивать достаточно высокую гарантию того, что данные будут читаемы, даже если вдруг в этой области вылезет бэд. а проверка завершенности записи будет производиться при чтении: в заголовке транзакции будет храниться ее контрольная сумма, и в случае, если на самом деле транзакция недописалась из-за несвоевременного выключения питания, это будет заметно и исправимо.
то есть после записи блока _сразу_ производить его чтение ? чтобы произвести его проверку.

ЗЫ. чем больше служебной информации, необходимой для поддержания структур ФС, причем необходимой сразу при чтении файла (для быстрого доступа к нему, чтобы не читать каждый раз двухсторонний список блоков файла с диска), которую надо держать в памяти, тем сложнее поддерживать синхронизацию этих структур в памяти и на диске.
 
Цитата
buggzy пишет:
кстати, ситуацию, когда из-за несвоевременного выключения питания потерялись данные из сектора, тоже будет исправлена нижним уровнем.
метод написания программы сверху вниз ? когда описываем идеальную прогу, а все проблемы будет делать за нее "нижний уровень" ?

IMHO, если нижний уровень будет обеспечивать надежность записи по секторно (то есть запишет и проверит что записалось, если нет, то переместит), еще и проверит что в сектор все записалось или нет, то зачем какая-то хитрая файловая система ? и FAT32 покатит
и тогда стоит сразу перейти к обсуждению этого хитрого нижнего слоя
 
Цитата
buggzy пишет:
> Загрузи досовский scandisk. Он показывает бэд блоки, если даже они "замещены" резервными.

интересно, как запустить досовский скандиск на ntfs? и еще - скандиск давно научился работать со smart? ;)
S.M.A.R.T. - Self-Monitoring Analysis and Reporting Technology.
Так при чем тут вообще smart?
 
> хорошо ты все-таки ввел понятие блока. чем он отличается от сектора ? ты же вроде хотел побайтовые потоки организовать... хотя без разбиение информации на блоки не обойтись, железо же работает наиболее эффективно именно с блоками.

блок отличается от сектора тем, что он может иметь размер 1 или 31337 байт (плюс заголовок), в отличие от сектора.

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

> то есть после записи блока _сразу_ производить его чтение ? чтобы произвести его проверку.

зачем? ты знаешь, что такое избыточные данные?

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

связанный список нужен только для учета свободного места на диске и будет использоваться только при записи, причем держать его весь в памяти нет никакой необходимости, использоваться будут только первые несколько элементов.
 
кстати, если по причине говорить (что NTFS сыпется) то это скорее не из-за винта, а может быть из-за памяти...
 
> метод написания программы сверху вниз ? когда описываем идеальную прогу, а все проблемы будет делать за нее "нижний уровень" ?

нет, просто я акцентирую обсуждение на нерешенных вопросах. вопросы с нижним уровнем мне уже кажутся решенными :)

> и FAT32 покатит
нижний уровень умеет защищать от аппаратных сбоев, но не умеет следить за целостностью файловой системы, которая нарушается из-за несвоевременного выключения питания.
 
где-то слышал сказку, что умные винты, когда у них появляются бэд, умеют делать вид, что ничего не случилось. просто информация с сектора теряется и все :) а испорченный сектор прозрачно для IDE мапится на резервный. и никто об этом не узнает :)
 
> кстати, если по причине говорить (что NTFS сыпется) то это скорее не из-за винта, а может быть из-за памяти...

у меня сыпалась из-за винта. сменили - перестало.
 
Цитата
Michael пишет:

Загрузи досовский scandisk. Он показывает бэд блоки, если даже они "замещены" резервными. Не на всех файловых системах, конечно :) Еще это умеет делать NDD (Norton Disk Destroyer) под винды из пакета NU.
Цитата
buggzy пишет:
где-то слышал сказку, что умные винты, когда у них появляются бэд, умеют делать вид, что ничего не случилось. просто информация с сектора теряется и все :) а испорченный сектор прозрачно для IDE мапится на резервный. и никто об этом не узнает :)

Повторю. Он показывает бэд блоки, если даже они "замещены" резервными.
 
Цитата
Michael пишет:
Цитата
buggzy пишет:
> Загрузи досовский scandisk. Он показывает бэд блоки, если даже они "замещены" резервными.

интересно, как запустить досовский скандиск на ntfs? и еще - скандиск давно научился работать со smart? ;)
S.M.A.R.T. - Self-Monitoring Analysis and Reporting Technology.
Так при чем тут вообще smart?

SMART -- это единственное место, откуда можно достать инфу о физических relocations на харде.
 
> Повторю. Он показывает бэд блоки, если даже они "замещены" резервными.

ок, и я повторю, помедленее и попонятнее. скандиск показывает список плохих блоков, помеченных файловой системой и НЕ ИСПОЛЬЗУЮЩИХСЯ (странно, что тебя не смутило слово "замещены"). он не умеет читать из smart список блоков, заменой которых занимается фирмварь :)
 
Цитата
buggzy пишет:

блок отличается от сектора тем, что он может иметь размер 1 или 31337 байт (плюс заголовок), в отличие от сектора.
то есть блоки переменного размера ? в зависимости от данных которые будем записывать ? объясни все-таки подробнее как ты будешь контролировать свободное место

Цитата
buggzy пишет:

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

Цитата
buggzy пишет:

> то есть после записи блока _сразу_ производить его чтение ? чтобы произвести его проверку.

зачем? ты знаешь, что такое избыточные данные?
тока давай не будем переходить к твоему любимому флейму, который начинается как раз после таких риторических вопросов ок ?
просто объясни какой механизм избыточности будет реализован: по записи информации на диск ака дублирование блоков, по дополнительной проверке записанной информации.
и кто будет реализовывать эту избточность: нижний слой или драйвер ФС?

Цитата
buggzy пишет:

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

связанный список нужен только для учета свободного места на диске и будет использоваться только при записи, причем держать его весь в памяти нет никакой необходимости, использоваться будут только первые несколько элементов.
рассмотрим в принципе небольшой файлик данных (метров на 10) с маленькими записями (байт по 512), где добавления новых записей будут проходить нечасто, а вот нужно будет постоянно читать и редактировать существующие. если я правильно понимаю, на каждую запись потребуется свой блок(ака транзакция, так как они будут записываться независимо) ты предлагаешь весь список не держать в памяти, а подчитывать по мере необходимости с диска ?
 
тема опять плавно перетекает от создания надежной ФС во флейм умеет багзи пользоваться скандиском или нет
 
Цитата
buggzy пишет:
> Повторю. Он показывает бэд блоки, если даже они "замещены" резервными.

ок, и я повторю, помедленее и попонятнее. скандиск показывает список плохих блоков, помеченных файловой системой и НЕ ИСПОЛЬЗУЮЩИХСЯ (странно, что тебя не смутило слово "замещены"). он не умеет читать из smart список блоков, заменой которых занимается фирмварь :)
Короче, рассказываю ситуевину.
Диск слегка подпорченный.
fdisk. Создаю один active primary partition на весь диск.
format c: /u
Если я не ошибаюсь, в конце получаю:
... available
... free
0 bad

chkdsk
0 bad

scandisk
смотрю карту поверхности. вижу эти бэды.
 
> то есть блоки переменного размера ? в зависимости от данных которые будем записывать ? объясни все-таки подробнее как ты будешь контролировать свободное место

блок - это заголовок + данные. блоки бывают двух видов - "свободные" и "занятые".

заголовок свободного блока:
1: флаг занятости (0)
2: адрес предыдущего свободного блока
3: адрес следующего свободного блока

заголовок занятого блока:
1: флаг занятости (1)
2: адрес предыдущего свободного блока (это не опечатка)
3: адрес следующего свободного блока

процедура выделения блока:
1. правим флаг занятости
2. изменяем поле "адрес следующего свободного блока" у предыдущего свободного блока, изменяем поле "адрес предыдущего свободного блока" у следующего свободного блока (теперь они указывают друг на друга).

процедура освобождения блока:
1. правим флаг занятости
2. "склеиваем" рядомстоящие свободные блоки, если это возможно (четыре варианта: склеить не удалось, удалось склеить только с предыдущим, удалось склеить только с последующим, удалось склеить три блока в один), правим ссылки свободных блоков, чтобы они оставались корректными (не стал расписывать)

> тока давай не будем переходить к твоему любимому флейму

я просто интересовался, надо тебе это объяснять, сам знаешь или не поленишься где-нибудь прочитать. ладно, остановимся на первом варианте.

избыточность - это не дублирование. избыточность - это способ кодирования информации, позволяющий ценой увеличения объема обнаруживать и/или исправлять потери или искажения информации. например, передача вместе с данными их md5 хеша - это избыточное кодирование, позволяющее с большой вероятность (вероятность ошибки - 2^-128) обнаруживать ошибку передачи, а RAID-5 - избыточное кодирование, позволяющее восстанавливать данные при потере специфически выбранной их части. дублирование - это лишь частный случай избыточного кодирования с теми же характеристиками, что и RAID-5 (сейчас на меня накинутся начитавшиеся умных книжек про то, что RAID-5 - это не зеркалирование).

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

> ты предлагаешь весь список не держать в памяти, а подчитывать по мере необходимости с диска ?

в памяти держится список транзакций открытого файла, а не список всех блоков диска :)
 
> тема опять плавно перетекает от создания надежной ФС во флейм умеет багзи пользоваться скандиском или нет

сразу вспоминается анек "ять!.. ать!.. ать!" - по привычке отозвалось эхо...
 
Цитата
buggzy пишет:

блок - это заголовок + данные. блоки бывают двух видов - "свободные" и "занятые".

заголовок свободного блока:
1: флаг занятости (0)
2: адрес предыдущего свободного блока
3: адрес следующего свободного блока

заголовок занятого блока:
1: флаг занятости (1)
2: адрес предыдущего свободного блока (это не опечатка)
3: адрес следующего свободного блока

процедура выделения блока:
1. правим флаг занятости
2. изменяем поле "адрес следующего свободного блока" у предыдущего свободного блока, изменяем поле "адрес предыдущего свободного блока" у следующего свободного блока (теперь они указывают друг на друга).

процедура освобождения блока:
1. правим флаг занятости
2. "склеиваем" рядомстоящие свободные блоки, если это возможно (четыре варианта: склеить не удалось, удалось склеить только с предыдущим, удалось склеить только с последующим, удалось склеить три блока в один), правим ссылки свободных блоков, чтобы они оставались корректными (не стал расписывать)

С таким механизмом ты теряешь в эффективности и в надежности. Слишком много операций нужно совершить.
Гораздо проще держать две-три битовые карты на свободный/несвободный, каталог со структурами -- описаниями и данные. Т.е. NTFS в чистом виде. Лучше не придумаешь -- будет низкая производительность и меньшая устойчивость.

Цитата
buggzy пишет:

избыточность - это не дублирование. избыточность - это способ кодирования информации, позволяющий ценой увеличения объема обнаруживать и/или исправлять потери или искажения информации. например, передача вместе с данными их md5 хеша - это избыточное кодирование, позволяющее с большой вероятность (вероятность ошибки - 2^-128) обнаруживать ошибку передачи, а RAID-5 - избыточное кодирование, позволяющее восстанавливать данные при потере специфически выбранной их части. дублирование - это лишь частный случай избыточного кодирования с теми же характеристиками, что и RAID-5 (сейчас на меня накинутся начитавшиеся умных книжек про то, что RAID-5 - это не зеркалирование).
А RAID5 и не есть зеркалирование. Думаю эта ссылка решит все споры: RAID 5: Independent Data disks with distributed parity blocks.
Кстати говоря, при использовании помехозащитного кодирования с избыточностью, какова вероятность восстановления исходного сигнала при ошибках ? И при каком кол-ве искажений помехозащитный код позволяет "вернуть все как было" ?

Цитата
buggzy пишет:

нижний уровень будет реализовывать избыточное кодирование, обеспечивающее хорошую вероятность обнаружения физического сбоя (crc-32) и восстановление всех данных в случае сбоя специфической части железа (нужно специально выбрать ее так, чтобы свести к минимуму вероятность невосстановимого сбоя).
Это уже получается автономная самовосстанавливающаяся система. Т.е. другими словами будет операционка в операционке -- это не есть гуд, сильно все усложняется и вероятность возникновения сбоя только увеличивается. А CRC вместе с ECC уже давно применяется. Кста, разговор, я надеюсь, ещё о хардах идет или уже о других носителях (каких ?)

Цитата
buggzy пишет:

> ты предлагаешь весь список не держать в памяти, а подчитывать по мере необходимости с диска ?

в памяти держится список транзакций открытого файла, а не список всех блоков диска :)
А при вырубании питания все эти транзакции идут лесом ?
 
> С таким механизмом ты теряешь в эффективности и в надежности. Слишком много операций нужно совершить.

ачёйта вдруг? операция освобождения выполняется только в процессе "консолидации". а операция выделения фактически затрагивает только заголовок текущего блока, запись в заголовки предыдущего и последующего попадет в кеш отложенной записи.

> А RAID5 и не есть зеркалирование.
ну вот, я же говорил! :)

разве я утверждал, что raid 5 - зеркалирование? я говорил "с теми же характеристиками" :) поясняю: raid-5 из N носителей делает носитель объема N-1, при этом обеспечивая восстановление в случае потери одного из них. подставьте N=2 - получите характеристики зеркалирования :)

> Это уже получается автономная самовосстанавливающаяся система.

это ты о чем? :) разделение на уровни - чисто условное.

> А при вырубании питания все эти транзакции идут лесом ?

те, что не успели сохраниться на диск - да. а при запуске после сбоя фс проверяется и восстанавливается до последнего вменяемого значения :) в том-то вся прелесть задумки, что отложенная запись целостоность фс не испохабит.

> Лучше не придумаешь -- будет низкая производительность и меньшая устойчивость.

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

я пользовался и ntfs, и reiserfs, и вижу, что они - не панацея. при неправильном выключении питания сыпятся, а иногда и без оного - тоже. думаю, остальные современные файловые системы не лишены тех же недостатоков. лично я думаю, что они - не идеал, а компромисс (между устойчивостью и производительностью), но мне иногда поведение этого компромисса не нравится :)
Страницы: Пред. 1 2 3 4 След.
Читают тему