USB --> RS232

Tue Jun 14 2005 01:58, George Shepelev wrote to Kirill Frolov:

GS> У меня есть "досовская" версия Modest Forth с замечательной защитой от GS> глюков - _все_ пользовательские данные каждой "задачи", включая шитий код GS> и стеки, лежат в отдельном сегменте X86 и никак не могут повлиять на GS> остальную систему. Работает значительно надёжнее, чем Win 98 ;)

В то, что сегменты X86 могут иметь любой стартовый адрес, кратный 16, но их размер может достигать 64К, и, как следствие, один и тот же адрес может быть доступен из 64K / 16 - 1 = 4095 разных сегментов тебя совсем не смущает :) ?

GS> Для отказоустойчивости применяют специальные приёмы, к примеру GS> дублирование или регулярный бэкап критической информации. Прекрасно GS> реализуется под DOS'ом.

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

KF>> Как в досе "смонтировать" FS в режиме read-only?

GS> Перехватить обработчик прерывания 13h и блокировать запись для GS> указанного носителя данных. Пишется и отлаживается за день. Теперь GS> попробуй рассказать, как под виндой смонтировать сидюк с UDF на пишущем GS> приводе в режиме read-only ;)

См. выше (*). А причем здесь MS Windows? Разве что Embedded, и то сильно сомнительно.

GS> Странно, куча людей (мне тоже доводилось) восстанавливали данные с GS> носителей под FAT'ом.

Молодцы! А те, у кого не так много времени на изобретение велосипеда :) , используют файловые системы с журналированием.

KF>> Кроме того, именно что придётся /восстанавливать/ для продолжения KF>> работы. Вот, к примеру, если я в текстовом редакторе пишу письмо и KF>> будет отключено питание, то какая часть файла останется на диске после KF>> этого? Это зависит от того записан ли сам FAT, записан ли каталог, KF>> записан ли сам файл и в какой последовательности это всё происходило KF>> (что при использовании разного рода дисковых кешей опять-же никем не KF>> гарантируется)...

GS> Это зависит от правильной настройки софта и аккуратности работы в GS> прикладной программе (регулярное сохранение данных).

См. выше (*).

С уважением, Денис

Tue Jun 14 2005 14:28, Denis Y. Borisov wrote to George Shepelev:

DYB> From: "Denis Y. Borisov" snipped-for-privacy@stav.ru

GS>> Странно, куча людей (мне тоже доводилось) восстанавливали данные с GS>> носителей под FAT'ом.

DYB> Молодцы! А те, у кого не так много времени на изобретение велосипеда :) DYB> , используют файловые системы с журналированием.

Вы думаете, что там ничего не пропадает ?

SY, EK

Denis, ты ещё здесь сидишь?

Вторник Июнь 14 2005 13:28, Denis Y. Borisov wrote to George Shepelev:

GS>> У меня есть "досовская" версия Modest Forth с замечательной GS>> защитой от глюков - _все_ пользовательские данные каждой GS>> "задачи", включая шитий код и стеки, лежат в отдельном сегменте GS>> X86 и никак не могут повлиять на остальную систему. Работает GS>> значительно надёжнее, чем Win 98 ;) DB> В то, что сегменты X86 могут иметь любой стартовый адрес, кратный 16, DB> но их размер может достигать 64К, и, как следствие, один и тот же DB> адрес может быть доступен из 64K / 16 - 1 = 4095 разных сегментов тебя DB> совсем не смущает :) ?

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

GS>> Для отказоустойчивости применяют специальные приёмы, к примеру GS>> дублирование или регулярный бэкап критической информации. GS>> Прекрасно реализуется под DOS'ом. DB> * Правильно, зачем пользоваться чем-то, изначально приспособленным под DB> нашу задачу? Мы лучше возьмем что-то совершенно неподходящее, но DB> хорошо нам знакомое, усложним так, чтобы пользоваться станет на DB> порядок неудобнее, зато наш внтуренний мир останется в DB> неприкосновенности :) .

Ты прав. Дублирование и регулярный бэкап - как раз методы, изначально придуманные для увеличения отказоустойчивости. В отличие от попыток заложиться на "надёжность" какой-либо файловой системы.

KF>>> Как в досе "смонтировать" FS в режиме read-only? GS>> Перехватить обработчик прерывания 13h и блокировать запись для GS>> указанного носителя данных. Пишется и отлаживается за день. GS>> Теперь попробуй рассказать, как под виндой смонтировать сидюк с GS>> UDF на пишущем приводе в режиме read-only ;) DB> См. выше (*).

А чего там смотреть? Я дал простой и понятный ответ на твой вопрос. Подобные методы широко использовались во времена DOS'а.

DB> А причем здесь MS Windows?

При том, что обсуждавшаяся файловая система NTFS появилась в Windows, дальше см. выше (*)

GS>> Странно, куча людей (мне тоже доводилось) восстанавливали данные GS>> с носителей под FAT'ом. DB> Молодцы! А те, у кого не так много времени на изобретение велосипеда

Этот "велосипед" давно изобретён и успешно используется.

DB> :) , используют файловые системы с журналированием.

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

Георгий

Wed Jun 15 2005 14:35, George Shepelev wrote to Denis Y. Borisov:

GS> Denis, ты ещё здесь сидишь?

DB>> А причем здесь MS Windows?

GS> При том, что обсуждавшаяся файловая система NTFS появилась в Windows, GS> дальше см. выше (*)

GS>>> Странно, куча людей (мне тоже доводилось) восстанавливали данные GS>>> с носителей под FAT'ом. DB>> Молодцы! А те, у кого не так много времени на изобретение велосипеда

GS> Этот "велосипед" давно изобретён и успешно используется.

DB>> :) , используют файловые системы с журналированием.

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

Вы хотите сказать, что известное качество NTFS более качественно чем неизвестное некоторым танкистам качество FS с журналированием ? ;-)

SY, EK

Привет, Evgeny !

15 Jun 05 , 14:23 Evgeny Kotsuba писал к Denis Y. Borisov:

DYB>> Молодцы! А те, у кого не так много времени на изобретение DYB>> велосипеда :) , используют файловые системы с журналированием.

EK> Вы думаете, что там ничего не пропадает ?

Смотря что журналировать. Если журналировать данные, то в худшем случае, по идее, поимеем не последнее, а предпоследнее состояние.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Использующие дюймовую систему действительно не ищут легких путей.

Evgeny, ты ещё здесь сидишь?

Четверг Июнь 16 2005 18:56, Evgeny Kotsuba wrote to George Shepelev:

GS>> Дело хозяйское, если у них есть время на разборки с неизвестного GS>> качества "системой с журналированием". Которая тоже далеко не GS>> панацея... EK> Вы хотите сказать, что известное качество NTFS более качественно чем EK> неизвестное некоторым танкистам качество FS с журналированием ? EK> ;-)

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

Георгий

Hello Evgeny!

Jun 16 19:56 05, Evgeny Kotsuba wrote to George Shepelev:

EK> Вы хотите сказать, что известное качество NTFS более качественно чем EK> неизвестное некоторым танкистам качество FS с журналированием ? EK> ;-) reiserfs - это с журналированием? У меня дважды умирала. При том что ext2fs - ни разу. Имеется в виду конечно не по причине издыхания железа. Правда в этом случае я ext2fs ухитрился вручную из кусков собрать(не сильно сложнее чем fat кстати). Кстати - для эксперимента можете попробовать поставить Линукс на fat и посмотреть насколько машина _субъективно_ быстрее шевелиться начнет. Hу или для знатоков - OS/2 на ext2fs - такое тоже _возможно_, и сразу видно как полуось начинает тормозить. Вот обратная сторона "продвинутости" файловых систем...

Zahar

Wed Jun 15 2005 14:35, George Shepelev wrote to Denis Y. Borisov:

GS>>> Для отказоустойчивости применяют специальные приёмы, к примеру GS>>> дублирование или регулярный бэкап критической информации. DB>> нашу задачу? Мы лучше возьмем что-то совершенно неподходящее, но DB>> хорошо нам знакомое, усложним так, чтобы пользоваться станет на GS> Ты прав. Дублирование и регулярный бэкап - как раз методы, изначально GS> придуманные для увеличения отказоустойчивости. В отличие от попыток GS> заложиться на "надёжность" какой-либо файловой системы.

Ты даже не понимаешь о чём говоришь. Это совершенно разные вещи. И одно только дополняет второе, но никак не может являться заменой. Откуда ты можешь знать, какая копия из твоего дубля является актуальной?

Mon Jun 20 2005 12:24, Zahar Kiselev wrote to Evgeny Kotsuba:

ZK> Hello Evgeny!

ZK> Jun 16 19:56 05, Evgeny Kotsuba wrote to George Shepelev:

EK>> Вы хотите сказать, что известное качество NTFS более качественно чем EK>> неизвестное некоторым танкистам качество FS с журналированием ? EK>> ;-)

ZK> reiserfs - это с журналированием? У меня дважды умирала. При том что Честно скажу - без понятия. У меня опыт только с JFS.

ZK> ext2fs - ни разу. Имеется в виду конечно не по причине издыхания железа. ZK> Правда в этом случае я ext2fs ухитрился вручную из кусков собрать(не ZK> сильно сложнее чем fat кстати). ZK> Кстати - для эксперимента можете попробовать поставить Линукс на fat и ZK> посмотреть насколько машина _субъективно_ быстрее шевелиться начнет.

ZK>Hу ZK> или для знатоков - OS/2 на ext2fs - такое тоже _возможно_, и сразу видно ZK> как полуось начинает тормозить. Вот обратная сторона "продвинутости" ZK> файловых систем... ну-ка, ну-ка, расскажи как поставить OS/2 на ext2fs

SY, EK

Hello Evgeny!

Jun 20 16:48 05, Evgeny Kotsuba wrote to Zahar Kiselev:

EK> ну-ка, ну-ка, расскажи как поставить OS/2 на ext2fs В 97 году лично ставил. Есть специальный французский если не ошибаюсь загрузчик. Естественно, полуосные ЕА идут лесом,но warp 3 у меня работал, находясь не только на одном диске, но и на одном разделе с линуксом(Дебиан

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

Zahar

Mon Jun 20 2005 21:50, Zahar Kiselev wrote to Evgeny Kotsuba:

ZK> Hello Evgeny!

ZK> Jun 20 16:48 05, Evgeny Kotsuba wrote to Zahar Kiselev:

EK>> ну-ка, ну-ка, расскажи как поставить OS/2 на ext2fs

ZK> В 97 году лично ставил. Есть специальный французский если не ошибаюсь ZK> загрузчик. Естественно, полуосные ЕА идут лесом,но warp 3 у меня работал, ZK> находясь не только на одном диске, но и на одном разделе с ZK> линуксом(Дебиан 1.2). ну ты орел ZK> Вот только могут быть проблемы с многогигабайтными ZK> дисками - у меня эта конструкция на 1.2G жила, а на большой винч не ZK> ставилась, не помню сколько он был, вобщем загрузчик на нем вис при ZK> пуске. Hу, сейчас народ поступает проще - берет пробирку и пускает XP под осью или линукс или еще как.

SY, EK

Привет, Zahar !

20 Jun 05 , 12:24 Zahar Kiselev писал к Evgeny Kotsuba:

ZK> можете попробовать поставить Линукс на fat и посмотреть насколько ZK> машина _субъективно_ быстрее шевелиться начнет. Hу или для знатоков - ZK> OS/2 на ext2fs - такое тоже _возможно_, и сразу видно как полуось ZK> начинает тормозить. Вот обратная сторона "продвинутости" файловых ZK> систем...

В ext2 крайне тормозной алгоритм поиска в директории.

. С уважением, Hикита. icq:240059686, lj-user:nicka_startcev ... Добросовестно и усердно веселиться?!

Tue Jun 21 2005 21:26, Nickita A Startcev wrote to Zahar Kiselev:

ZK>> можете попробовать поставить Линукс на fat и посмотреть насколько ZK>> машина _субъективно_ быстрее шевелиться начнет. Hу или для знатоков - ZK>> OS/2 на ext2fs - такое тоже _возможно_, и сразу видно как полуось ZK>> начинает тормозить. Вот обратная сторона "продвинутости" файловых ZK>> систем... NAS> В ext2 крайне тормозной алгоритм поиска в директории.

Насколько я понимаю, он крайне тормозной только при первом проходе -- линейный поиск. И только если в каталоге есть достаточно большое число записей, в противном случае всё будет ровно наоборот. Будете спорить, объясните мне, почему когда я в люнихе нажимаю Tab два раза и вижу список файлов через секунду, а когда я делаю тоже самое в виндовсе под msys то списка файлов ранее чем через десяток-второй секунд не дождусь.

*** Ответ на письмо из carbonArea (carbonArea).

Привет, snipped-for-privacy@fk0.pp.ru !

24 Jun 05 , 15:21 Kirill Frolov писал к Nickita A Startcev:

ZK>>> можете попробовать поставить Линукс на fat и посмотреть ZK>>> насколько машина _субъективно_ быстрее шевелиться начнет. Hу или ZK>>> для знатоков - OS/2 на ext2fs - такое тоже _возможно_, и сразу ZK>>> видно как полуось начинает тормозить. Вот обратная сторона ZK>>> "продвинутости" файловых систем... NAS>> В ext2 крайне тормозной алгоритм поиска в директории.

KF> Hасколько я понимаю, он крайне тормозной только при первом проходе KF> -- линейный поиск.

Да. Hа более продвинутых fs оно получше.

KF> объясните мне, почему когда я в люнихе нажимаю Tab два раза и KF> вижу список файлов через секунду, а когда я делаю тоже самое в KF> виндовсе под msys то списка файлов ранее чем через десяток-второй KF> секунд не дождусь.

msys/cygwin - это отдельное угрёбище с какими-то странными противоестественно-большими тормозами при выводе на консоль.

. С уважением, Hикита. ... Я пью до дна за тех, кто в танке!

Hello, Alexander V. Lushnikov! You wrote in conference fido7.ru.embedded to Kirill Frolov on Mon, 20 Jun 2005 22:39:33

+0400:

GS>>> Ты пpав. Дублиpование и pегуляpный бэкап - как pаз методы, GS>>> изначально пpидуманные для увеличения отказоустойчивости. В GS>>> отличие от попыток заложиться на "надёжность" какой-либо GS>>> файловой системы.

KF>> Ты даже не понимаешь о чём говоpишь. Это совеpшенно pазные вещи. KF>> И одно только дополняет втоpое, но никак не может являться KF>> заменой.

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

KF>> Откуда ты можешь знать, какая копия из твоего дубля является KF>> актуальной?

AVL> А для этого, как ни стpанно, существуют пpовеpочные коды, AVL> контpольные суммы и пpочие сpедства пpовеpки целостности AVL> данных. Сюpпpиз, да?

Так вот как раз бэкап обычно и совмещает дублирование с такими средствами проверки целостности. Главное на момент бэкапа быть уверенным в валидности сохраняемых данных.

dima