Не поможет даже 1-битная табличка. Могу предложить только вариант с деревом высокого порядка (несбалансированным, балансировка в рамках диска + 8-битной платформы - это убийство), причем дерево лишнего места на диске занимать не будет.Сообщение от Vladimir Kladov
интересно будет посмотреть
Даю чуток обрезанное (дабы не было "левых" декодеров, если кто поймет, откуда это) описание (кое-что там под вопросом, но суть реализации FS будет ясна).интересно будет посмотреть
Sector 0 is superblock (block 0, block 1 is copy):
0000 0004 ID1 [3FFFFFFF]
0004 0001 ID2 (???) [20]
0005 0002 Version (???) ([0102] for 1.02)
0007 0001 Superblock length - 1 (???)
0008 0004 Block size (bytes) [00004000]
000C 0002 System area start (???) [03EC]
000E 0002 System area length (???) [0020]
0010 0004 File area length in sectors [000074A0]
0014 0002 Superblock block [0000]
0016 0002 Superblock copy block [0001]
0018 0002 Remap area block [0002]
001A 0002 Remap area length [0005]
001C 0002 File data area start block [0007]
001E 0002 File data area length [03A5]
0020 0002 Remap data area start block [03AC]
0022 0002 Remap data area length [0040]
0024 0002 System area start (???) [03EC]
0026 0002 Filler (???) [0000]
Remap area:
Basically filled with FFs. Non-FF parts begin with [3FFFFFFF] ID and
structured as follows:
0000 0004 ID [3FFFFFFF]
0050 xxxx Remap table (2 byte logical block numbers for corresponding
remap area block, FFFF = not used)
Data blocks 1-2: FAT16 (each sector begins with [0000] [FFFF] where [0000] is corresponding FAT part number, there are 4 FATs, FE blocks each, totalling 3F8 blocks max, [0000] in FAT means stop, [FFFF] means unused).
Data block 3: root directory
Directory structure:
0000 0080 Filename hashes (sums)
0080 xxxx Entries
Directory entry:
0000 0001 Type (2 - directory, 1 - file)
0001 0001 Filename hash
0002 0002 [FFFF]
0004 0004 Block pointer
0008 0004 Some kind of attributes
000C 0004 [00000000]
0010 0004 For '.' record - length (in records) + 1,
[00000000] for other directories,
length in bytes for files
0014 006C Filename (ASCIIZ)
да, еще можно связать все свободные кластеры в одну цепочку при форматировании, и выделять кластеры, "забирая" их из списка по очереди. Но это только откладывает проблему на потом. Потом когда при удалении файлов они "возвращаются" в список свободных кластеров, возникает жуткая фрагментированность на свободных блоках. А вот если есть табличка "занятости", то можно освобожденные кластеры засовывать сразу в правильное место в списке, проверяя, что соседние кластеры свободны или нет.
да не надо в точности до отдельных смещений, лучше бы просто русскими словами... из этого не понятно, зачем нужен remap - это против битых секторов? как система обрабатывает фрагменты?
Remap - это "журнал транзакций". В ремап дату записываются сами сектора, которые будут перезаписаны (каталоги, FAT), а затем проставляется отметка транзакции в ремап, которая указывает, какие сектора куда (в ремап дату) переехали.
Фрагменты обрабатываются как в FAT.
Из всего этого очень полезна будет транзакциональность и хеширование имен файлов в каталогах.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Хммм, давно устоялась привычка делать все описания на английском ж)лучше бы просто русскими словами
Правильно!!! =) тем более, что ник твой smart file system на амиге =)
Неа) Ник от SfinxSoftware) Я так на взломанных прогах подписывался )
А если серьезно - то для дискеток и флешек FAT - самое то. А вот для винта - однозначно лучше чтото ext-подобное.
SFS
Всем сюда=)
http://sourceforge.net/projects/smartfilesystem/
Может будет интересно
Или сюда: http://www.amiga.org.ru/
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
