turnon 1 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 23 minutes ago, jcxz said: И что? При след. запуске проверка сектора покажет, что он не стёрт при маркере не равном корректному -> запустится стирание сектора заново. Некорректный маркер может оказаться и у страницы "не дырки". В этом случае мы потеряем положение головы и стиранием этого сектора с некорректным маркером можем уничтожить (потерять) много секторов с полезными данными. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 3 минуты назад, turnon сказал: Некорректный маркер может оказаться и у страницы "не дырки". Каким образом? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 47 minutes ago, jcxz said: Каким образом? Например, страница износилась и не читается то что было записано. Или сбой питания во время записи маркера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 4 минуты назад, turnon сказал: Например, страница износилась и не читается то что было записано. Или сбой питания во время записи маркера. Если "страница износилась", то никакой алгоритм работать не будет. Или можете предложить такой, который будет? А если "сбой питания во время записи маркера" - видимо после нового старта запись повторится. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 6 minutes ago, jcxz said: А если "сбой питания во время записи маркера" - видимо после нового старта запись повторится. Так ведь дырку будет невозможно найти, или в лучшем случае надо будет ее искать проверкой на полную стертость каждого сектора. 6 minutes ago, jcxz said: Если "страница износилась", то никакой алгоритм работать не будет. Или можете предложить такой, который будет? Писать рядом с маркером нарастающий индекс (нарастает при каждом стирании сектора). Если последняя страница (голова) не прочитается - по индексу можно будет понять где прыдыдущая и потерять только один сектор. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 6 минут назад, turnon сказал: Так ведь дырку будет невозможно найти, или в лучшем случае надо будет ее искать проверкой на полную стертость каждого сектора. Возможно найти. Вы внимательнее алгоритм почитайте. А то складывается впечатление, что и не читали вовсе. Там специально описан этот момент. 19.03.2020 в 08:32, jcxz сказал: Запись данных ведётся всегда таким образом, что перед головой в любой момент времени должен быть как минимум один полностью стёртый сектор (т.е. - если хотим записать страницу данных в голову, то сначала проверяем сколько останется полностью стёртых секторов перед головой после записи страницы и, если меньше одного сектора - стираем предыдущий сектор, а затем уже - пишем страницу. Таким образом в любом случае, даже если при предыдущей попытке записи данных был сбой питания и записался мусор, то всегда программа сможет найти голову КОХ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба Извините, если недопонял Ваш алгориим. Получается голова определяется по одному сектору, в случае каких-либо проблем с содержимым или чтением этого сектора позиция головы теряется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 11 января, 2022 Опубликовано 11 января, 2022 · Жалоба 31 минуту назад, turnon сказал: Получается голова определяется по одному сектору, в случае каких-либо проблем с содержимым или чтением этого сектора позиция головы теряется. Минимум одному. Ищется граница перехода "стёртый сектор" / "сектор с валидным маркером". В случае каких-либо проблем с любыми данными или чтением их, эти данные теряются. Где бы и как бы они не были записаны. Причём тут тогда? Боитесь этого? Тогда дублируйте данные. Точно также как и в любой другой системе хранения. К моему алгоритму это не имеет отношения. И какие могут быть проблемы и почему они должны случиться? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба В алгоритме с индексом в каждом секторе потеря последнего сектора-"головы" (с самым большим номером) не приводит к полной потере головы, просто принимаем за голову предыдущий сектор. В Вашем алгоримте потеря сектора-дырки приводит к полной потере головы и началу записи с 0-го сектора, а это потеря не одного сектора с данными, в худшем случае - всех. Поправьте пожалуйста, если я неправильно понял. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба 2 часа назад, turnon сказал: В алгоритме с индексом в каждом секторе потеря последнего сектора-"головы" (с самым большим номером) не приводит к полной потере головы, просто принимаем за голову предыдущий сектор. Что за "алгоритм с индексом"? 2 часа назад, turnon сказал: В Вашем алгоримте потеря сектора-дырки приводит к полной потере головы и началу записи с 0-го сектора, а это потеря не одного сектора с данными, в худшем случае - всех. Ещё раз спрашиваю: Каким образом эта самая потеря сектора-дырки может случиться? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба 26 minutes ago, jcxz said: Что за "алгоритм с индексом"? Например как в Piconomix FW Library: "To figure out which page contains the oldest records (FIRST page) and which page contains the newest records (LAST page), a rolling (or wrapping) number is assigned to each page. This means that each consecutive page is labelled with an incrementing number. If the number exceeds the maximum, it starts again at zero (rolls over)." 26 minutes ago, jcxz said: Ещё раз спрашиваю: Каким образом эта самая потеря сектора-дырки может случиться? Это не столь важно. Просто возьмем случай что сектор не читается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба 26 минут назад, turnon сказал: Например как в Piconomix FW Library: "To figure out which page contains the oldest records (FIRST page) and which page contains the newest records (LAST page), a rolling (or wrapping) number is assigned to each page. This means that each consecutive page is labelled with an incrementing number. If the number exceeds the maximum, it starts again at zero (rolls over)." А где там алгоритм? Без алгоритма невозможно судить ни о чём: ни о устойчивости к сбоям питания и др. событиям. Цитата Это не столь важно. Просто возьмем случай что сектор не читается. Странный аргумент.... Вот предположим вы написали программу. А теперь я говорю: "Предположим, что вот эта команда кода не читается. В этом случае ваша программа перестанет работать. Значит программа неустойчива к пропаданию команд кода. А почему команды из кода могут не читаться - не важно." PS: Кстати - по той вышеприведённой вами ссылке, если сектор перестанет читать, алгоритм тоже перестанет работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба 8 minutes ago, jcxz said: PS: Кстати - по той вышеприведённой вами ссылке, если сектор перестанет читать, алгоритм тоже перестанет работать. Так как раз будет работать. Если взять за основу принцип - в каждом секторе есть индекс. Всегда можно найти сектор с самым большим индексом - голову или самый близкий к голове, даже если среди них попадутся нечитаемые. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 184 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба 38 минут назад, turnon сказал: Так как раз будет работать. Если взять за основу принцип - в каждом секторе есть индекс. Всегда можно найти сектор с самым большим индексом - голову или самый близкий к голове, даже если среди них попадутся нечитаемые. А смысл? Если сектора не читаются, то и записать что-то нельзя - значит устройство неработоспособно. И считанный вами сектор - какой от него толк? Вот например у меня конфиг имеет размер предположим = 256 байт; сектор = 256КБ. Итого сектор вмещает ~1024 конфига. Предположим последний сектор (голова) перестал читаться, читаем предыдущий -> получаем конфиг каким он был 1024 изменения назад; скорей всего - ещё от предыдущей версии ПО, т.е. - не совместимый с текущей версией. Да даже если совместимый - какая польза от такого древнего конфига? PS: И про тот алгоритм по ссылке нет никакой информации о его устойчивости к сбоям питания. А значит априори считаем что он неустойчив к ним. И может и все данные потерять. Или перепутать положение головы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
turnon 1 12 января, 2022 Опубликовано 12 января, 2022 · Жалоба 1 hour ago, jcxz said: Предположим последний сектор (голова) перестал читаться, читаем предыдущий -> получаем конфиг каким он был 1024 изменения назад Нет, если не удалось прочитать последний сектор, читаем предпоследний - тот что был 1 изменение назад. Ну и у меня там хранятся архив измерений с датчика, потерять 1 сектор - не так критично как потерять весь объем фоеша из-за порчи местоположения головы. 1 hour ago, jcxz said: PS: И про тот алгоритм по ссылке нет никакой информации о его устойчивости к сбоям питания. А значит априори считаем что он неустойчив к ним. И может и все данные потерять. Или перепутать положение головы. Там как раз все потерять нельзя, потому как все сектора равнозначны, нет какого-то специфичного, как в Вашем алгоритме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
