[aaarrr 63]

2 minutes ago, mantech said:

журнал поможет не испортить списки файлов, но какой прок, если нужные данные пропадут

В том и прок - не обрушить ненароком метаданные ФС. Если система не имеет резервного источника питания, то она по определению может терять данные при аварии.

[mantech 33]

1 минуту назад, aaarrr сказал:

Если система не имеет резервного источника питания, то она по определению может терять данные при аварии.

Я уже это давно пытаюсь доказать, но jcxz со мной принципиально спорит...

[jcxz 184]

19 минут назад, aaarrr сказал:

Если система не имеет резервного источника питания, то она по определению может терять данные при аварии.

Каким образом? Вы считаете, что разработчики журналирующих ФС "по определению" ошибаются? Смелое заявление! Можете обосновать? 

16 минут назад, mantech сказал:

Я уже это давно пытаюсь доказать, но jcxz со мной принципиально спорит...

Я с вами не спорю - глупо спорить с фактами. Описание работы журналирующей ФС доступно - докажите, что алгоритм в корне не верен и не работоспособен.  

 

PS: Похоже у нас образовалось своё собственное общество плоскоземельщиков. 

 

1 час назад, turnon сказал:

если в disk_write приходит на запись больше одного сектора - последовательно писать сначала в журнал. затем на носитель. Журнал размером 512 байт храним на том же носителе.

Похоже Вы не поняли принципа работы журналирующей записи....

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

[aaarrr 63]

13 minutes ago, jcxz said:

Вы считаете, что разработчики журналирующих ФС "по определению" ошибаются?

Да нет, это вы ошибаетесь в части интерпретации понятия "потеря данных". Речь, разумеется, не о потере уже записанных данных при аварии, а о текущих, готовящихся или находящихся в процессе записи. В первом случае и абсолютно надежная™ ФС, основанная на абсолютно надежных™ самописных библиотеках, совершенно не спасет.

[jcxz 184]

4 минуты назад, aaarrr сказал:

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

А где я такое говорил???   Приведите конкретную цитату пожалуйста!

Вы передёргиваете и приписываете мне то, чего не было.

Естественно журналирующая ФС спасает уже записанные данные и саму структуру ФС. О чём и шла речь.

Данные в ОЗУ спасти невозможно. В принципе. И обратного я нигде не утверждал.

[aaarrr 63]

2 minutes ago, jcxz said:

А где я такое говорил???   Приведите конкретную цитату пожалуйста!

Да здесь вот:

Или "говорите такое", или же приписываете мне то, чего не было. Уж одно из двух.

[jcxz 184]

7 минут назад, aaarrr сказал:

Или "говорите такое", или же приписываете мне то, чего не было. Уж одно из двух.

И что? Напоминаю вам тему дискуссии: Разговор идёт о ФС (файловой системе).

Вы сказали, что "Если система не имеет резервного источника питания, то она по определению может терять данные при аварии.", исходя из контекста обсуждения - Вы говорили о ФС и о том, что она каким-то образом теряет данные. Ещё раз: обоснуйте - каким образом система может терять данные?

[aaarrr 63]

3 minutes ago, jcxz said:

исходя из контекста обсуждения - Вы говорили о ФС и о том, что она каким-то образом теряет данные

Это ваша искаженная интерпретация. Причем намеренно искаженная - такой вот традиционно изящный полемический прием.

 

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

[jcxz 184]

Только что, aaarrr сказал:

Это ваша искаженная интерпретация. Причем намеренно искаженная - такой вот традиционно изящный полемический прием.

Нет. Это вы или не поняли темы обсуждения или поняли, но сознательно решили потроллить.

Тема обсуждения здесь: Устойчивость ФС к сбоям питания и внезапным перезагрузкам. Это если 1-й вариант...

[aaarrr 63]

3 minutes ago, jcxz said:

сознательно решили потроллить

Так куда резервный источник подключать будем?

[turnon 1]

2 hours ago, aaarrr said:

Потому что все не так просто. Попробуйте объяснить, чем и как поможет озвученный механизм "журналирования".

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

[aaarrr 63]

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

[turnon 1]

2 hours ago, jcxz said:

Похоже Вы не поняли принципа работы журналирующей записи....

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

Для меня цель устойчивой к сбоям ФС - не разрушить саму ФС, надо внести минимальные изменения, которые переведут систему в новое корректное состояние.

[jcxz 184]

32 минуты назад, turnon сказал:

Хотя тут напрашивается вопрос - а какое максимальное количсество секторов в FAT необходимо записать для переводы ФС из одного корректного состояния в другой.

Всё можно сделать проще. Я свою ФС, устойчивую к сбоям, реализовывал так:

Например имеем на диске файл, занимающий цепочку кластеров FAT:

0(1)-1(2)-2(3)-3(4)-4(EOF); остальные кластера диска свободны.

где: первая цифра - номер кластера; цифра в скобках - номер следующего кластера цепочки.

Требуется записать в файл данные начиная с N-го байта кластера 2 до M-го байта кластера 3.

1) Нахожу 2 свободных кластера в FAT (номера 5, 6). Пишу в них новую инфу, на лету комбинируя её с инфой из кластеров 2,3 (остаток их содержимого не перекрытый новыми данными).

2) После этого формирую (в ОЗУ) новую карту кластеров:

0(1)-1(5)-5(6)-6(4)-4(EOF); остальные кластера диска свободны.

3) Также в ОЗУ формирую новую запись каталога (у меня не было иерархии директорий - не нужна, для простоты, только корневая директория).

4) Создаю в журнале запись с новой FAT-таблицей и записью каталога.

5) Произвожу все необходимые изменения на диске (перезапись FAT, перезапись каталога).

6) Удаляю запись журнала.

Всё. Питание можно выключать в любой момент - ФС не пострадает.

Ограничение: В любой момент времени к началу запроса записи в ФС должно быть такое количество свободных кластеров, которое вместит любую однократную запись в файл.

[mantech 33]

1 час назад, jcxz сказал:

В любой момент времени к началу запроса записи в ФС должно быть такое количество свободных кластеров, которое вместит любую однократную запись в файл.

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

1 час назад, turnon сказал:

Для меня цель устойчивой к сбоям ФС - не разрушить саму ФС

А какой смысл в ФС, если будут страдать ваши данные в файлах в момент пересбросов?