Security Lab



Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
Форум » Общие » Общение на SecurityLab
Страницы: Пред. 1 2 3 4 След.
RSS
фс мечты
 
#41
Это нравится:0Да/0Нет
16.07.2003 15:19:16
Цитата
buggzy пишет:
> С таким механизмом ты теряешь в эффективности и в надежности. Слишком много операций нужно совершить.

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

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

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

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

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

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


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

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


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

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

Цитата
buggzy пишет:
я пользовался и ntfs, и reiserfs, и вижу, что они - не панацея. при неправильном выключении питания сыпятся, а иногда и без оного - тоже. думаю, остальные современные файловые системы не лишены тех же недостатоков. лично я думаю, что они - не идеал, а компромисс (между устойчивостью и производительностью), но мне иногда поведение этого компромисса не нравится :)
raiserfs я не трогал (даже не знаю что это =), но на данный момент любая FS сыпется при внезапном выключении питания.

Панацея, на мой взгляд, одна -- аппаратное решение. Софтверно улучшить -- можно, но кардинально решить проблему -- нет. Все, есстесно, имхо.
 
 
 
#42
Это нравится:0Да/0Нет
16.07.2003 16:52:53
> Кэш есть хорошо для скорости, но не для надежности.

не надо общих рассуждений. аналогий тоже не надо. надо логику и мысли.

> Но отца русской демократии это не спасет, т.к. сбой может произойти и в момент отложенной записи.

а доказать?
 
 
 
#43
Это нравится:0Да/0Нет
16.07.2003 17:47:56
2All: давайте на время не будем обсуждать SMART, RAID и прочие умные аббревиатуры. Нахeра оно нам?

2buggzy:
Я немного не понял, а как выглядит "транзакция" из которых состоит файл на диске? Можешь набросать структурку на С?

;------
;NK
 
 
 
#44
Это нравится:0Да/0Нет
16.07.2003 18:03:56
> Можешь набросать структурку на С?

элемент списка транзакций файла
{
tr_table_offset prev, next; // предыдущая и след запись таблицы

// адрес первой позиции относительно начала файла
file_offset   begin;

// длина блока данных
file_offset   length;

// адрес блока данных на устройстве
device_offset  blockaddr;

#ifdef ono_nam_nado
timestamp ts;
#endif
}

блок данных на диске
{
flag  allocated; // (а может его стоит запихнуть в следующее поле?)
device_offset  prev; // предыдущий блок
device_offset  next; // следующий блок
device_offset  length; // длина блока в единицах девайса
crc_type  crc; // контрольная сумма, у занятого блока должна быть правильной, у незанятого - правильной+1
unsigned char data[0]; // а тута начинаются данные...
}

операция чтения читает список транзакций файла (с конца), находит нужную, идет по ссылке из нее и читает что надо с диска.

операция записи выделяет блок на диске, записывает в него данные и добавляет в список транзакций новый элемент, ссылающийся на выделенный блок.
 
 
 
#45
Это нравится:0Да/0Нет
16.07.2003 18:14:19
предупреждая закономерный вопрос "нахрена все это":

я хочу придумать систему, которая давала бы сбоеустойчивость, близкую к абсолютной (то есть чтобы было нереально дожить до того дня, когда она даст сбой). и пока что мне кажется, что это удается. причем защита будет не только от сбоев фс, но и от сбоев в результате некорректного завершения приложения - достаточно будет сделать откат к той позиции, когда состояние фс было приемлимым. ну и плюс некоторая защита от некорректных действий оператора.
 
 
 
#46
Это нравится:0Да/0Нет
16.07.2003 18:23:28
>я хочу придумать систему, которая давала бы сбоеустойчивость, близкую к абсолютной

Когда увидим бета-версию, или хотя бы 0.0.1, или ты это только для себя делаешь? :)
 
 
 
#47
Это нравится:0Да/0Нет
16.07.2003 18:34:03
Цитата
buggzy пишет:
я хочу придумать систему, которая давала бы сбоеустойчивость, близкую к абсолютной (то есть чтобы было нереально дожить до того дня, когда она даст сбой). и пока что мне кажется, что это удается.

Я думаю, ты не первый, кому это кажется. Первым был "изобретатель" CDFS. Данная система, будучи закатанной на CDROM, обладает "сбоеустойчивостю, близкой к абсолютной".

Видишь ли, пока ты не определишься с железом, бесполезно что-либо проектировать -- все равно хорошо будет только на бумаге.
 
 
 
#48
Это нравится:0Да/0Нет
16.07.2003 18:36:20
а с железом давно определился - /dev/hda ;)

p.s. еще раз призываю - не надо всяческих "общих соображений", с них толку ноль.
 
 
 
#49
Это нравится:0Да/0Нет
16.07.2003 19:44:14
Интересно. А ещё один вопрос: на каждый write будет выделяться строго одна транзакция соответствующего length, или будет буферизация/фрагментация запросов write по отношению к транзакциям? Надеюсь ты понял, что я хочу спросить? :)

;--------
;NK
 
 
 
#50
Это нравится:0Да/0Нет
16.07.2003 19:54:56
необходимость фрагментации тут уже упоминалась, а вот буферизация противоречит концепции системы.

вообще-то если система пишет в файл по байту на уровне API, значит, ее создателю этого сильно хочется. потому что в большинстве средств программирования буферизация записи встроена в средства работы с файлами.
 
 
 
#51
Это нравится:0Да/0Нет
16.07.2003 19:56:32
имелось в виду _принудительная_ буферезация встроена...
 
 
 
#52
Это нравится:0Да/0Нет
16.07.2003 20:33:27
Ну вот представим себе такую прогу:

int main(int ac,char** av)
{
printf("Please wait while formatting drive C: [");
for (int i=0;i<25;i++)
{
 printf(".");
 fflush();
 sleep (100);
}
printf("]\nDone\n");
return 0;
}

После каждой точки прогресс-бара я вставляю fflush чтобы юзер видел реальную скорость работы незамутненную буферизацией.
А потом запускаю эту программу вот так
bash$ ./a.out > log.txt
Хочешь ли ты чтобы IdealFS создавала на кажду точку новую транзакциюв файле log.txt?

;------
;NK
 
 
 
#53
Это нравится:0Да/0Нет
16.07.2003 20:37:21
Поправочка - лучше наверное сказать не IdealFS а DreamFS, или просто DFS :)

;---
;NK
 
 
 
#54
Это нравится:0Да/0Нет
16.07.2003 20:45:28
> Хочешь ли ты чтобы IdealFS создавала на кажду точку новую транзакциюв файле log.txt?

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

подумай, в каких случаях на самом деле используется fflush для дискового файла, и правильно ли навязывать буферизацию в этих местах.
 
 
 
#55
Это нравится:0Да/0Нет
16.07.2003 20:53:33
Так в том-то и дело, что в приведенном мною примере fflush не предназаначался для работы с диском, программер предполагал что он делает printf на консоль. А вот юзеру захотелось редиректнуть stdout :)
Суммируя: Возможен случай когда программер ошибочно отказывается от буферизации вывода, то есть это не обусловлено логикой программы. В случае с обычной FS это даст только некоторый оверхед при работе программы, а в случае DFS - мы имеем программу которая с пулеметной скоростью плодит бессмысленные транзакции, тем самым забивая место на диске. Как бы решить эту проблему?

;--------
;NK
 
 
 
#56
Это нравится:0Да/0Нет
16.07.2003 21:06:28
эх... в принципе, можно откладывать формирование транзакции на незначительное время, на надежность это особо повлиять не должно.
 
 
 
#57
Это нравится:0Да/0Нет
16.07.2003 21:17:30
Нет, это не есть Good Thing™. Получается что у тебя системный вызов fflush длает не fflush, а х знает что.
Можно установить квоту на количество транзакций для файла и по истечении её делать принудительную консолидацию. Это спасет общий объем диска от засирания, но сделает возможность undo непрозрачной для прикладного софта. То есть, чтобы файл можно было откатить, программа создавшая/изменявшая его должна будет соблюдать определенные правила. Совсем не то... Тут думать надо.

PS: я не верю что фс спроектированная по заявке из корневого поста будет "абсолютно отказоустойчивой" в твоей терминологии. ИМХО, сдохнет винт - сдохнет том :)
А вероятность такого исхода одного порядка с вероятностью сброса питания при незаписанном кэше фс.
;-------
;NK
 
 
 
#58
Это нравится:0Да/0Нет
16.07.2003 22:00:16
> Получается что у тебя системный вызов fflush длает не fflush, а х знает что.

fflush - это не системный вызов. это просто сигнал для сишной обертки FILE сбросить свои (прикладные, а не системные) буферы на диск.
 
 
 
#59
Это нравится:0Да/0Нет
17.07.2003 06:36:45
мне кажется все таки стоит еще определится - эта DreamFS предполагает восстановление пользовательских данных ? или только служебной информации ФС ?

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

предвидя негодования багзи - да конечно, если проблемы в железе винта то и NTFS может упасть (на этот счет они же предусмотрели ftdisk.sys, насколько я помню что-то типа софтверного раида, хотя точно не помню просьба не наезжать)
единственная проблема для тебя с NTFS наверно в том что она может обеспечивать избыточность только на _нескольких_ винтах, ты же хочешь чтобы она делала эту избыточность на одном (я так понимаю путем записи избыточной информации в разные места диска). так ?
 
 
 
#60
Это нравится:0Да/0Нет
17.07.2003 07:11:52
Цитата
buggzy пишет:

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

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

я непонял (учитывая далее сказанное) существуют блоки и транзакции, это не одно и тоже, где-то на диске еще и хранится список транзакция файла ? учитывая то, что  в блоках про транзакции ни слова ?

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

процедура выделения блока:
1. правим флаг занятости
2. изменяем поле "адрес следующего свободного блока" у предыдущего свободного блока, изменяем поле "адрес предыдущего свободного блока" у следующего свободного блока (теперь они указывают друг на друга).
а если между этими шагами произойдет сбой ? они ведь явно разнесены по диску и поэтому сделать это все одной атомарной операцией не получится. налицо сбой в ФС и требуется алгоритм восстановления. в NTFS это делается журналом транзакция изменений файловой системы то есть если все операции не завершились то откат к началу выделения (учти, я говорю не про транзакции записи в файл, а про запись служебной информации ФС)
и кстати, стоит предусмотреть процедуру разбиения свободного блока на части (сам говорил они могут быть разного размера), потому как если надо записать 10 байт, а найден свободный блок в 10Кб? не будешь бить на части - будут остатки кластера в чистом виде (аля FAT)

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

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

нижний уровень будет реализовывать избыточное кодирование, обеспечивающее хорошую вероятность обнаружения физического сбоя (crc-32) и восстановление всех данных в случае сбоя специфической части железа (нужно специально выбрать ее так, чтобы свести к минимуму вероятность невосстановимого сбоя).
хорошо, давай поговорим подробнее про избыточность, ты так все прекрасно объяснил .
обознач пожайлуста, какую степень избыточности будет обеспечивать нижний уровень? то есть какой минимум вероятности ты определяешь для своей ФС?
если RAID-5 настроен на один избыточный винт, то при потере одного винта инфа легко восстанавливается, однако что будет при потере _двух_ винтов? я так понимаю это событие рассматривается как имеющее очень маленькую вероятность (все таки винты, хотя ... если блок питания начнет сбоить и выдавать скачки напруги внутрь компа).
соответственно, если ты хочешь обеспечения избыточности на _одном_ винте (средствами ФС) ты явно должен это делать посредством избыточных блоков. так вот уточни количество этих избыточных блоков для твоих нужд, так как всего _один_ избыточный блок (как в RAID-5 N носителей дает N-1 надежный носитель) на умирающем винте я думаю не спасет отца русской демократии

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

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

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