Подумалось... (про ФС)

locate

Оно!

Интересно почему его везде не встраивают, в тот же mc...

все и так вроде в памяти. просто find вместо того чтобы использавать несуществующий вызов "найти файл по паттерну" сам перебирает каждый.

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

Ну так тогда непонятно, почему бы не сделать на уровне поддержки ФС в ядре любые операции с каталогами в оперативке? Тогда и отдельной приблуды не надо, даже тупой find с перебором всех каталогов будет выполняться за долю секунды. Ну да, относительно много памяти под это дело надо, но при нынешних гигах оперативки это не проблема.

о, как! а ну-ка прикиньте сколько понадобится памяти для ядерной реализации этой фичи? у меня в каталоге и его подкаталогах 1 миллион файлов (а то и больше), сколько понадобится памяти в таком случае?

У меня файлов даже не 100000 и оперативки 2 гига :)

эти проблемы просто решаются потредовой конвееризацией и кешированием на диск

ну представь себе следующее - у тебя порядка 2 миллионов файлов ... сколько будет кушать? Потом опять же - в начале фс такое хранить ... нет ну тогда прийдется и на фс отжирать много места и в памяти, хотя да - можно, только кушать будет, иноды точнее их количество у тебя ограничено, в зависимости от их плотности на фс и определить отжираемый кусок можно, но только представь себе такой "кеш" у тебя размер блока 4096, размер иноды 4096, размер диска ну гигов 100 - сосчитай сколько ты отожрешь в памяти, на диске - ну и так далее.

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

прикольно.

в кюниксе такое реализовано? :)

Нах тогда диск вообще?

> Нах тогда диск вообще?

А саму информацию, что в файлах содержится, ты тоже в ОЗУ хранить собрался? Все мои 74 гига? :)

> в кюниксе такое реализовано? :)

Нет. Но хотелось бы, и не только в QNX :)

примерно так оно и происходит, просто как уже заметили файнд перебирает все файлы, у тебя ведь автодополнение путей в бэше не занимает столько же времени. А то, что ты тут "открываешь" используется при полнотекстовом поиске в движках вроде beagle и strigi, там изменения на фс через inotify применяются на бд с кэшем. Для просто быстрого поиска файлов по имени как уже заметили есть locate. Вроде все на своих местах:)

а на адресацию сколько ты при этом пожрешь ? я ж тебе сказал что подсчитай сколько тебе скушать надо - бредовая затея короче.

Ладно, если стану когда-нибудь кернел-хацкером, поманьячу по этому поводу, может чего интересное получится. :)

> [...] Всё равно дерево каталогов где-то хранится, вернее размазано по диску, но ведь оно есть, информация о файлах объём какой-то занимает всё равно. Просто не размазывать его по диску, выделить сколько-то там мегов в начале диска [...]

поздравляю, Вы изобрели FAT

> поздравляю, Вы изобрели FAT

Что-то я не видел там [почти] мгновенного поиска по имени файла. Долго и нудно хрустело хардом, как и любая другая ФС.

>Что-то я не видел там [почти] мгновенного поиска по имени файла. Долго и нудно хрустело хардом, как и любая другая ФС.

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

тебе мгновенный поиск по имени файла нужен настолько сильно и часто, что ты готов отдать под это дело неслабый % производительности на дисковый операциях и еще поиметь еще одно уязвимое место (что будет например при битой оперативе или данных) ? Еще раз: постоянное кеширование более или менее оправдано на расширенных поисковых задачах (музыка по исполнителю через теги, полнотекстовый поиск и проч.). Его пытались встроить в новую фс для виста, но как раз и напоролись на издержки такой структуры. В остальных случаях дешевле проектировать апликухи линкующиеся по полному пути в дереве фс (+ теже симлинки и переменные окружения). А для пользователей - обновляющийся раз в сутки локейт.

Значит WinFS это оно и было?

да, вобщем даже намного больше чем фс с быстрым поиском, читай тут:

http://en.wikipedia.org/wiki/WinFS

есть вроде и живые альтернативные проекты на эту тему, даже в ленте проскакивало.

Добро пожаловать в идеологию DBFS.

Только после подлянки от MS в виде закрытия проекта WinFS, на Linux оно теперь в обозримом будущем не появится :-/

мне существующий вариант с кешированием поисковиками представляется надежнее и производительнее(хотя иметь интерфейс к фс позволяющий "выбрать * файлы из дерева созданные василием пупкимным за две недели начиная с дд.мм.гггг пакетом superoffice" конечно заманичиво). А то придется акромя забытой дефрагментации вспомнить про оптимизацию и нормализацию:)

1. Есть такой термин - профиль нагрузки. Так вот find - это крайне редкий профиль. И тот, кто делает find, в большинстве своем фигней страдает, а не активной работой занят

2. Ответь себе на вопрос, что такое VFS и чем занимается его кэш?

И напоследок... У команды grep есть ключик -R (рекурсивный обход всех файлов и каталогов) - он знаешь какой медленный?!

> У меня файлов даже не 100000 и оперативки 2 гига :)

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

>о, как! а ну-ка прикиньте сколько понадобится памяти для ядерной реализации этой фичи? у меня в каталоге и его подкаталогах 1 миллион файлов (а то и больше), сколько понадобится памяти в таком случае?

Ужас =)
Решил пересчитать:
# find / -type f | wc -l
175466

Нет миллиона
И, думаю, что мало у кого есть =)
Хотя и это дохрена памяти отъест.

> # find / -type f | wc -l
> 175466

У меня 295346 :-)

749014 :) Львиная доля -- maildir-Ы

Кстати, есть такая штука rlocate, этот тот же locate токо там еще есть и ядреный модуль который отслеживает создание и удаление файлов. Поэтому база данных файлов всегда (почти) up-to-date и не надо ждать когда отработает updatedb. У меня стоит на генту и вполне нормально работает...

Раз пошло такое дело:

>locate * | wc -l
2009471

ЗЫ. Это мой домашний комп, не сервер =)

> Знаешь, ты бы лучше один гиг из них продал, а на полученные деньги купил рыбы. Типа фософор - основа мысли и улучшает работу моска, чего тебе не явно помешает...

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

Куда уж очевидней...

Есть дисковый кеш.

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

Что собственно и требуется. И даже не надо ничего менять...

> Тормозит поиск->тормозит изза того что читает с харда->вынести дерево каталогов в оперативу.

Вот тебе информация к размышлению - это приведено время срабатывания трех запусков find подряд:

$ time find . | wc -l

real 0m21.163s

$ time find . | wc -l

real 0m1.497s

$ time find . | wc -l

real 0m0.435s

Этот тест, кстати, проделан на ноутбуке с 256 мегабайтами памяти. Система изначально при старте адаптировалась под нагрузку "работа в GNOME", закэшировав glib/gtk/gdk. Когда я начал гонять ее find'ами, она сбросила файловый кэш в пользу кэширования списка инодов файловой системы /usr.

Еще это означает, что у системы и так есть прекрасно работающий умный кэш, который писали профессионалы и который абсолютно корректно работает если в нем действительно есть нужда (на третьем повторе весь find оказался практически мгновенным) - то есть если профиль нагрузки включает сплошные find'ы - то они очень скоро становятся достаточно быстрыми.

Есть еще голая математика - пусть как в моем примере, поиск по закэшированным метаданным ФС занимает 0.5 секунды, загрузка метаданных с ФС в память - 20 секунд. Монтирование без предчтения метаданных в память одну секунду, а твой вариан монтирования с предчтением - 21 секунду (собственно монтируем и грузим в память, верно?)

Тогда общее время на монтирование и десять операций find для нынешней ФС составит 1+(20+0.5)+9*0.5=26 секунд, а для твоей идеи (20+1)+0.5*10=26 секунд. Выигрыша нет никакого. Вот только если памяти мало, то ты со своей реализацией вообще не смонтируешь ФС (некуда тебе свое оглавление девать!), а нынешняя схема сработает - пусть и не самым быстрым образом.

А если тебя так приспичило сделать такую "суперфичу" - вот тебе решение:

$ cat qnxmount
#!/bin/sh
mount $@
find `echo $@ | tr " " "\n" | tail -1`
{ while true; do find `echo $@ | tr " " "\n" | tail -1` ; done; sleep 5; } &

Этот скрипт тебе смонтирует ФС и ее тут же закэширует. И будет поддерживать в закешированном состоянии. Теперь ты щаслив?

> Всё должно быть устроено просто и очевидно

Вот сейчас оно именно так: если нужно часто - значит будет в кэше. Если нах не надо - пусть не мешает.

> Да у меня-то с мозгом всё в порядке, а вот у вас...

Извиняй, но вышепоказанные примеры оставляют ощущение того, что у тебя значительная часть моска использована для кэширования ктулху :-)

P.S.: могу прислать тебе баночку кильки в томатном соусе - там еще окромя фосфора и витаминчик C, и кальция много :-)

P.P.S.: да не дергайся ты - я тоже молодым был и лажался, да так что сейчас вспоминать стыдно

>Кстати, есть такая штука rlocate, этот тот же locate токо там еще есть и ядреный модуль который отслеживает создание и удаление файлов

Кстати, поставил себе недавно. Интересно, оно тормозит работу с FS или нет? :)

По логике вещей там должно быть два компонента - ядерный трекер и юзерспейсовый апдейтовый демон, общающиеся через специальный файл в /sys или /dev. То есть с одной стороны тормозов нет, а в сдругой... Смотря на какие события оно дергается - если на create/delete/rename - то не тормозит, а если на каждый апдейт иноды, тогда "оооо....", особенно если не включена опция noatime :-)

В общем, вчера включил... Пока особо не тормозит, вроде. Хотя машина почти как всегда загружена. Работаю без noatime :)

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

Хотя, конечно, это всё далеко не DBFS :) Вот когда будет система запросов по произвольным приписываемым файлу атрибутам... Эх... :)

Самое приятное, если идеи DBFS станут массовыми, напрочь отпадёт надобность в костылях в виде тэгов MP3 или Ogg, EXIF в JPEG, всяких descript.ion и т.д. и т.п... Всё это можно будет стандартно хранить в файловых атрибутах и иметь мгновенный поиск по всей FS...

Хотя бы наши внуки до такого доживут, интересно? :)

Надеюсь, не доживут. Контрреволюция не пройдёт! Даёшь плоские файлы! :)

>Надеюсь, не доживут. Контрреволюция не пройдёт! Даёшь плоские файлы! :)

Нет, лучше многомерные =)))))))))