'Обратная' файловая система?
В развитии вопрос я спросил относительно StackOverflow, какие-либо файловые системы существуют, где данные записаны "конец передней" или "нижней части к вершине", а не от начала до конца?
А именно, я ищу (возможно, специальное) способ сохранить файлы журнала в самой недавней первой форме (а-ля, как блоги и новостные сайты организованы с новым на вершине).
Такой зверь существует? Если так, что это, и где это должно быть найдено?
6 ответов
То, что Вы просите, не является просто “обратной” файловой системой. Вы хотите структурированную записью, “инвертированную” файловую систему, т.е. рекордную файловую систему, где запись, добавленная в последний раз, кажется первой в файле. На самом деле обратный аспект был бы, вероятно, реализован как, “можно вставить запись перед первой существующей записью”.
Интерфейсы файловой системы, найденные в операционной системе, обычно найденной на ПК (Unix, Windows и еще более экзотические), структурированы байтом только — у них нет понятия записи. Таким образом, Вам не повезло.
Один возможный подход должен был бы сделать каждую запись в журнале отдельным файлом в каталоге. Затем пересеките каталог в обратном порядке времени создания файла, или в обратном порядке имен при предоставлении монотонно увеличивающихся имен к записям в журнале. Так как у Вас, вероятно, будет большое количество записей в журнале, любой удостоверяется, что использовал файловую систему, которая поддерживает большие каталоги хорошо (например, на Linux reiserfs и ext3 с dir_index функция в порядке, но ext2 не), или иначе используйте подкаталоги (один для первых 1 000 записей, один для следующих 1000 и так далее).
Другой подход должен был бы использовать более сложную базу данных, например, та, которую можно запросить в SQL и просто выбрать записи в обратном порядке из их создания (SELECT message FROM logs ORDER BY date DESC).
Я не совсем уверен, что ни один не существует, но я, конечно, никогда не слышал об одном. Если бы они могут быть сделаны, я должен думать, что были бы некоторые главные недостатки.
Предварительное ожидание в файл обычно требует полной копии существующих данных. В файловой системе Вы смогли обрабатывать его к добавлению блока к началу файла, но это все еще вызывает несколько незначительных проблем. Блоки со свободным пространством должны были бы сохранить свободное пространство вначале, таким образом, оно очень вероятно потребует дополнительного поиска диском найти надлежащее местоположение.
Обработка свободного пространства на диске, при работе назад, стала бы сильной болью. Это противоречило бы большинству методов программирования, так как необходимо будет найти макс. индекс и затем работать назад оттуда.
Я могу предположить, что это замедлилось бы на больших файлах и определенно будет смешной вещью программировать.
Вместо того, чтобы найти обратную файловую систему, почему Вы не можете просто записать файл, как обычно, и проанализировать его наоборот? Разработайте основную схему форматирования сообщения, считайте файл и проанализируйте сообщения от него, затем отобразите их последний-к-первому. Если Вы только нуждаетесь в последних сообщениях, ищете в конец файла, затем обратно n сообщения. Это имело бы подобный результат, но с намного меньшим количеством работы и сопоставимой или лучшей производительности.
Необходимо разделить идеи устройства хранения данных и извлечения. Даже в блогах Вы упоминаете, записи, вероятно, сохранены во вперед хронологическом порядке, но отображены в обратном хронологическом порядке (игнорирующий то, что он сделал легче при помощи структурированного хранилища).
Можно было очевидно создать упрощенную систему структурированного хранилища, которая сохранит записи в знакомом, вперед заказывают с "записями" свободной формы, и переменная длина с указателями байтового смещения, сохраненными в файле ресурсов в формате фиксированной длины (64 бита поддерживали бы файлы более чем 18 миллионов терабайт). Поиск последней записи или nth запись или last - n запись в файле указателя, затем байт, на который это указывает в основном файле, была бы тривиальна и быстра. Прием, который позволили бы специальная файловая система или драйвер, должен будет сделать это атомарным и сделать файл ресурсов прозрачным.
Вы ищете порядок байтов, который является порядком байтов? Почему Вы хотели бы, чтобы файлы журнала были организованы на уровне файловой системы вместо того, чтобы просто приказать, чтобы он через позволил, говорят ls?
Если это о Порядке байтов, существует несколько доступных файловых систем.
Две мысли приходят на ум:
Некоторые системы управления версиями хранят первую версию управляемого файла полностью и всех последующих версий как изменения, где другие хранят текущую версию управляемого файла полностью и все предыдущие версии как изменения.
При записи событий во время выполнения в базе данных, а не плоском файле это может быть непрозрачно Вам, хранит ли база данных события последовательно, реверс последовательно, или случайно.
К сожалению, нет простого способа сделать то, что Вы хотите. Это потребовало бы переписывания всего файла каждый раз, когда запись добавляется. Это было бы МЕДЛЕННО и становится медленнее, когда файл растет. Я думаю лучшее, которое можно сделать, включенный журнал последовательности, который это инвертировало демонстрирующийся, но сохранило в "нормальном" порядке на диск. Любой дб SQL мог сделать это легко, но это может быть больше служебное, чем Вы хотите.