Где хранится структура файловой системы?

И при запросе, например, scandir, дергается диск и возвращается эта информация. Так ли это? Или все-таки вся эта структура загружается в память и все запросы адресуются памяти, а не диску?

Не так, и не так. Структуры хранятся на диске. Если они нужны, они оттуда считываются и остаются в кэше в ОЗУ. Если они нужны ещё раз, они берутся из кэша. Если нужно их изменить, то они меняются в кэше и записываются на диск (возможно, через время). Если кэш переполнен, то ненужные страницы удаляются, при этом незаписанные изменения записываются на диск.

То есть кеширование осуществляется общим механизмом кеширования ОС. Но, в общем, все это на диске.
Я поясню свою задачу. Нужно написать многопоточное(!) приложение для перебора файлов и папок в заданной папке. Но раз вся информация по-умолчанию дергается с диска, то от многопоточности будет больше тормозов, чем пользы, так как диск все равно один. Я прав?

ares4322

приложение для перебора файлов и папок

Что конкретно должно делать это приложение с файлами и папками каталогами?

а почему бы действительно не хранить копию суперблока в памяти для более быстрого доступа к диску?

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

А теперь представь, что система зависла, или питание вырубилось.

ИМХО, перебирать B-дерево параллельным алгоритмом не имеет смысла. Хотя… cast catap.

ну будет утрачено только то , что не успело из памяти на суперблок записаться. система зависла - это уже чп

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

Бред же.

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

Диск то однопоточный (голов одна), так что смысла нет. Разве что одним потоком сканировать диск, другим обрабатывать полученные данные.

мне кажется, что на синхронизацию потратится больше ресурсов. или нет?

Подозрительно напоминает утилиту «find».

не понятно что?

да туплю. речь про иноды . идея была в том что они будут читаться из памяти. и кстати писать изменения в память как раз не обязательно - только для быстроты чтения. только памяти наверное будет требовать много.

на синхронизацию потоков? «Нужно написать многопоточное(!) приложение» это ведь не я придумал

Программа должна быть еще и быстрой.
Так что придется определять, на одном ли диске находятся исходные папки (их может быть несколько). И если нет, то можно запускать поток для каждой. А если на одном, то хватит и одного потока.

Нет не прав. Потому что есть кэш и туда уже очень много успело загрузится. Допустим, ты считываешь данные об 1 файле - в кэше окажутся ещё и все те, которые рядом с ним. А значит, если их будут перебирать другие потоки, то они уже не обратятся к диску.

Я так понимаю, загрузка остальных файлов зависит от того, как в памяти располагается структура данных, хранящая инфу о файловой структуре. Если это массив, то да, Вы правы, а если нет (дерево или список), то, соответственно, не факт.

трудно почитать про VFS and FS ?

там не много насколько я помню.

1. забудь про «папки», папки - объекты в проводнике, или в его аналоге (dolphin, thunar, etc)

2. структура ФС хранится в каталогах. Каталог - это действительно каталог. см. что пишут википедики:

Катало́г (от греч. κατάλογος) — в общем случае, некий список информации об объектах, составленный с целью облегчения поиска этих объектов по какому-то признаку:

3. в EXT4 каталог действительно хранится в виде дерева, но это не играет роли: scandir(3) помещает каталог в массив в памяти. Это массив структур dirent. Он определён в /usr/include/bits/dirent.h

а ты предлагаешь считать все директории (списки файлов и их inode) в память.

Бред же.

может по твоему это и бред, но scandir(3) именно так и делает. Читай ман.

Прав. Твой выход - копировать файлы последовательно. А пользователю можно «нарписовать» и многопоточную картину происходящего.

Программа должна быть еще и быстрой.

а программа будет быстрее, только если ты выполняешь тяжёлые вычисления с каким-то файлами. Например раскладываешь числа на простые множители. Тогда да, используй многопоточность. можно просто тупо натравить процессы на один и тот же каталог, и создать список, в котором хранится состояние файла: 0 - никто не трогал, 1 - в обработке, 2 - готово. Процессы конечно должны обрабатывать только файлы №0.

Т.е. ты тоже предлагаешь прочитать ВСЕ директории (scandir'ом) в память при первой загрузке и там же (в памяти) их и хранить, по-ходу синхронизируя изменения с диском?

Отличный план!

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

и создать список

не список конечно, а дерево, для быстрого поиска. Кроме того, надо учесть, что два процесса могут захватить один и тот же файл (блокировку). Я бы не изобретал велосипед, а взял-бы mysql.

потоки ускорят выполнение, только если сканировать разные физические диски

так что такое это загадочное «сканирование»? Простой обход? тогда я не знаю, накладные расходы скорее всего превысят выигрыш. Если взять mysql как я предлагал, то будет в разы _медленнее_. Даже на разных дисках.

Да, простой обход. Накладные расхода на что? На синхронизацию? Если несколько потоков будут с одним физическим диском работать, то да, привысят, а если с разными, то наоборот. Все же упирается тут в ввод/вывод, хоть что-то и кешируется ОС.

tree -fi /path/to/catalog > file.log

или не?

Т.е. ты тоже предлагаешь прочитать ВСЕ директории (scandir'ом) в память при первой загрузке и там же (в памяти) их и хранить, по-ходу синхронизируя изменения с диском?

ага. а ЕЩЁ индекс, для быстрого поиска. и ещё mysql.

Отличный план!

откуда я знаю, КАКАЯ задача у ТСа? Он молчит как Зоя К.

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

Да, простой обход.

тогда забей. выигрыш если и будет, то очень небольшой.

Накладные расхода на что? На синхронизацию?

да. дерево ФС ты просто так не развернёшь. Смысл есть если только у тебя 100500 файлов и 3 каталога. Тогда ты можешь обходить чётные/нечётные файлы двумя потоками сразу. Или ещё больше потоков сделать. Вот только... Сколько будет работать scandir, разворачивая 1 каталог?

Программа должна быть многопоточной.

а... понял. Тогда сделай во втором потоке блекджек, а в третьем порносайт.

И при этом головка у диска все равно одна)

Если разные физические диски, то можно и несколькими потоками перебирать

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

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

Иначе ой.

А вообще что за задачу ты пытаешься решить?

Где хранится структура файловой системы? (комментарий)

Не совсем прав.

У диска есть конструктивная особенность — у него хорошее линейное чтение (быстрое), а при случайном чтение будет тратиться время на позиционирование головки (это главное и самое вкусное отличие HDD от SDD, ибо тут чтение идет за const время).

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

Но последним фактом я бы принебрег :)

сами файлы читать не надо. надо получать списков файлов в каталоге

а что именно ты хочешь делать в разных потоках?

$ time find /usr > /dev/null

real	0m20.118s
user	0m0.171s
sys	0m0.692s
$ time find /usr > /dev/null

real	0m0.343s
user	0m0.124s
sys	0m0.215s

второй раз это уже кэшированное.

сами файлы читать не надо. надо получать списков файлов в каталоге

ты ещё не понял, что каталог != папка. Но хотя-бы пишешь правильно. Дело в том, что тебе и надо читать файлы, только не простые, а каталоги. scandir(3) как раз этим и занимается.

второй раз это уже кэшированное.

а теперь попробуй ls -R

ТСу нужен сортированный список.

Нужно написать многопоточное(!) приложение для перебора файлов и папок в заданной папке

Сомневаюсь, что оно будет быстрее, чем $(find $DIR | sort)

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

а теперь попробуй ls -R

Будет то же самое:

$ sudo sh -c "time ls -R /var > /dev/null"

real	0m8.416s
user	0m0.039s
sys	0m0.141s
$ sudo sh -c "time ls -R /var > /dev/null"

real	0m0.057s
user	0m0.020s
sys	0m0.037s

Будет то же самое:

я понимаю. Я это к тому веду, что хотя задачу построения списка распараллеливать не нужно (нет профита), но вот задачу сортировки - можно и нужно. Т.е. задача ТС решаема, он её не с той стороны просто решает, видимо просто не заметил слово «упорядоченного».

ЗЫЖ а что не /usr/ Не дождался?

ЗЗЫЖ алиас на sudo сам придумал?