LINUX.ORG.RU
ФорумTalks

Вопрос о перезаписи данных и целостности данных на файловой системе. Оцените идею и нужность подобной файловой системы.

 , , ,


0

1

Предположим есть файловая система, она размещена на твердотельном накопителе не поддерживающим TRIM и прочие шутки.

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

  1. Какая то программа перезаписывает часть файла новыми данными.
  2. Файловая система пишет обновлённые данные в одну из ячеек с наименьшим циклом количеством циклов записи. То есть в свободную ячейку.
  3. Записывает в циклический журнал резервную копию информации о изменяемом файле
     номер_записи время_записи ID_файла количество_блоков список_блоков флаг_открытия_дескриптора
  4. Перезаписывает в файловом дескрипторе список блоков использованных для файла и увеличивает счётчик его изменений.
  5. Записывает в циклический журнал
     номер_записи время_записи ID_файла количество_блоков список_блоков флаг_успешного_завершения 
  6. Если дескриптор был перезаписан более порогового количества раз, то переносит его. Проводит аудит каждой ячейки и записывает в наиболее изношенные комбинацию блокировки и помещает её в карту ненадёжных блоков.
  7. При создании нового дескриптора или расширения его на свободные ячейки, счётчик изменений дескриптора повышает до максимального значения износа блоков на которых расположен дескриптор.
  8. Все битовые карты блоков отмечающих занятость, исправность и приблизительную изношенность хранятся в упакованном виде как разреженный массив, а при монтировании файловой системы распаковываются в оперативную память. В случае сбоя, формируются заново сканированием всех дескрипторов файлов.

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

Какие могут быть слабые места данной файловой системы кроме крайне медленной работы (будет сбрасывать данные малыми порциями) при заполненности близкой к максимальной?

Перемещено Shaman007 из development

☆☆☆

Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от metawishmaster

ну, мужики сетуют в drivers/ata/libata-core.c:
/* devices that don't properly handle queued TRIM commands */

Это про «queued TRIM», обычный TRIM работает.

amm ★★
()
Ответ на: комментарий от templarrr

Так на СО ты уже забил?

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

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от anonymous

Флэшка нужна чтобы фотку кота по-быстрому передать, какая в жопу целостность данных.

Вообще то что бы «по быстрому» передать фотки кота, флешку могут внезапно вытащить позабыв про «отмонтирование».

И ФС с программным TRIM нужна что бы увеличить ресурс шлешки.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

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

Вспомнилась строчка из какой-то книги: "...решил заработать денег, написав роман в трёх томах, но скоро бросил..."

Разработка какой-нибудь программы. Океей. Ждём рождения софтверного гиганта масштаба Oracle, не меньше.

Deleted
()
Ответ на: комментарий от rezedent12

что бы увеличить ресурс шлешки

Spoofing будет в восторге. Вот, один клиент уже есть. Правда, проблема - прибыли на нём не сделать((

Deleted
()
Ответ на: комментарий от rezedent12

решил вернутся к разработке какой нибудь программы.
файловая система

Чего мелочиться, пиши ядро сразу.

xtraeft ★★☆☆
()
Ответ на: комментарий от Deleted

Я так понимаю эта петушня соскучилась по общественному вниманию.

xtraeft ★★☆☆
()
Ответ на: комментарий от rezedent12

Ну понятно, старая игрушка надоела - вот переключился на новую.

templarrr ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.