LINUX.ORG.RU

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


0

1

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

Перемещено post-factum из general

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

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

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

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

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

ares4322

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

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

post-factum ★★★★★ ()

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

teod0r ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

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

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

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

Бред же.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ares4322 ()

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

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

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

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

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

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

Бред же.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ares4322 ()
Ответ на: комментарий от sdio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

drBatty ★★ ()

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

Иначе ой.

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

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

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

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

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

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

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

catap ★★★★★ ()
$ 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

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

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

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

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

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

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

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

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

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

ares4322 ()
Ответ на: комментарий от drBatty

а теперь попробуй 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
quasimoto ★★★★ ()
Ответ на: комментарий от quasimoto
Первый раз
$ time ls -R /usr > /dev/null

real    0m17.578s
user    0m2.080s
sys     0m1.724s

второй раз
$ time ls -R /usr > /dev/null

real    0m0.966s
user    0m0.425s
sys     0m0.538s

без сортировки
$ time ls -U /usr > /dev/null

real    0m0.005s
user    0m0.001s
sys     0m0.003s
sdio ★★★★★ ()
Ответ на: комментарий от quasimoto

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

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

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

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

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