только не предлагайте проверить

← →
niKo (2007-12-18 14:10) [0]

если в корневой дериктории диска 1000 папок, в каждой из них еще 1000, в каждой из которых еще по 1000, в которых по 5-20 файлов
очень интересует, при доступе к файлам включаться тормост будет?

← →
Riply © (2007-12-18 14:13) [1]

> [0] niKo (18.12.07 14:10)

А кто такой "тормост" ?

← →
clickmaker © (2007-12-18 14:19) [2]

> включаться тормост будет?

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

← →
niKo (2007-12-18 14:33) [3]

> clickmaker © (18.12.07 14:19) [2]
>
>
> > включаться тормост будет?
>
> если сильно газовать, то может и не будет.
> На самом деле при такой структуре будет тормозить получение
> списка файлов (особенно рексурсивного), а если под доступом
> имеется в виду именно чтение из файла - то здесь тормоза
> определяются степенью фрагментации, и то больше при случайном
> доступе, а не последовательном

да именно доступ к файлу(ам) для чтения.
спасиба!

← →
oldman © (2007-12-18 14:34) [4]

> в корневой дериктории диска 1000 папок, в каждой из них еще
> 1000, в каждой из которых еще по 1000, в которых по 5-20
> файлов

от 5 до 20 миллиардов файлов???
да ну его к псам.

← →
clickmaker © (2007-12-18 14:48) [5]

> [3] niKo (18.12.07 14:33)

а для чего такое может понадобиться?

← →
Рамиль © (2007-12-18 14:50) [6]

Досье на каждого житяля земли с запасом на будущее.

← →
Сергей М. © (2007-12-18 14:52) [7]

> включаться тормост будет?

"Тормост" придумали трУсы.

← →
niKo (2007-12-18 14:54) [8]

> clickmaker © (18.12.07 14:48) [5]
>
>
> > [3] niKo (18.12.07 14:33)
>
> а для чего такое может понадобиться?

> Рамиль © (18.12.07 14:50) [6]
>
> Досье на каждого житяля земли с запасом на будущее.

З.Ы. Это в переносном смысле 1000*1000*1000 может быть в корневом каталоге 30 дерикторий или больше в некоторых 100-200 файлов плюс 100-200 дерикторий в которых 100-200 файло плюс 100-200 дерикторий!

← →
Мда (2007-12-18 15:15) [9]

А чо, есть такое слово- дериктория?

← →
Правильный_Вася (2007-12-18 15:16) [10]

> Это в переносном смысле 1000*1000*1000 может быть в корневом
> каталоге 30 дерикторий или больше в некоторых 100-200 файлов
> плюс 100-200 дерикторий в которых 100-200 файло плюс 100-
> 200 дерикторий!

а перенос смысла по какому правилу осуществлялся?
поправка на дядю Васю учитывалась?
с каким коэффициентом?

← →
Riply © (2007-12-18 15:17) [11]

> [2] clickmaker © (18.12.07 14:19)
> На самом деле при такой структуре будет тормозить
> получение списка файлов (особенно рексурсивного)

А почему "особенно рексурсивного" ?

← →
clickmaker © (2007-12-18 15:24) [12]

> [11] Riply © (18.12.07 15:17)

заход в каждую из 1000 папок + в каждой из них заход в каждую из 1000...
разве не будет?
хотя бы относительно листинга только первой папки

← →
Riply © (2007-12-18 15:27) [13]

> [12] clickmaker © (18.12.07 15:24)
> заход в каждую из 1000 папок + в каждой из них заход в каждую из 1000...
> разве не будет?

Разумеется будет.
Но точно так же будет и просто при открытии одного файла.

← →
clickmaker © (2007-12-18 15:34) [14]

> [13] Riply © (18.12.07 15:27)

то есть?
если известен полный путь
C:\somefile.txt
или
C:\Folder15\Folder975\Folder999\somefile.txt

разница между открытием 2-го и 1-го будет сравнима с разницей между не- и рекурсивнм листингом?

← →
Riply © (2007-12-18 15:40) [15]

> [14] clickmaker © (18.12.07 15:34)
> если известен полный путь
> C:\somefile.txt
> или
> C:\Folder15\Folder975\Folder999\somefile.txt

> разница между открытием 2-го и 1-го будет сравнима с разницей между не- и рекурсивнм листингом?

Нет, с полным "рекурсивнм листингом" не сравнима,
но при открытии второго будет происходить следующее:
Каждый "узел" в имени будет открываться и в нем будет
идти поиск следующего узла.
И так пока не кончатся узлы.

Т.е. если мы не выводим все файлы, а рекурсивно ищем
строго определенный, то эта операция сравнима с его открытием.

← →
Riply © (2007-12-18 15:48) [16]

> [15] Riply © (18.12.07 15:40)
> Каждый "узел" в имени будет открываться и в нем будет

Плохо выразилась.
"Открываться" не совсем так как мы открываем, но очень похоже :)

← →
oldman © (2007-12-18 15:55) [17]

> Riply © (18.12.07 15:40) [15]
> Каждый "узел" в имени будет открываться и в нем будет
> идти поиск следующего узла.
> И так пока не кончатся узлы.

Хм...
А зачем тогда системе FAT и ROOT?

← →
Riply © (2007-12-18 16:09) [18]

> [17] oldman © (18.12.07 15:55)
> Хм...
> А зачем тогда системе FAT и ROOT?

Не поняла вопроса :(

← →
oldman © (2007-12-18 16:12) [19]

> Riply © (18.12.07 16:09) [18]

Я сомневаюсь, что система делает "поиск" каждого узла в имени, если дерево каталогов прописано в ROOT, а физический адрес файла в FAT.

← →
Riply © (2007-12-18 16:21) [20]

> [19] oldman © (18.12.07 16:12)
> Я сомневаюсь, что система делает "поиск" каждого узла в имени

На "не индексированно диске" это выглядит так (очень грубо).
В MFT ищется файл-рекорд, описывающий "Folder15"
Считывается.
Если он резидентный, то в нем ищется ссылка на файл-рекорд, описывающий Folder975,
иначе считывается не-резидентная область и ищеться в ней.
Считывается файл-рекорд для Folder975.
Если он резидентный, то .....
И т.д.

← →
ProgRAMmer Dimonych © (2007-12-18 16:25) [21]

> Riply © (18.12.07 16:21) [20]
> На "не индексированно диске" это выглядит так (очень грубо).
> В MFT ищется файл-рекорд, описывающий "Folder15"
> Считывается.
> Если он резидентный, то в нем ищется ссылка на файл-рекорд,
> описывающий Folder975,
> иначе считывается не-резидентная область и ищеться в ней.
> Считывается файл-рекорд для Folder975.
> Если он резидентный, то .....
> И т.д.

А для меня ещё раз можно? А то я чего-то почувствовал себя полным недоумком. :) Попроще бы...

← →
guav © (2007-12-18 16:25) [22]

> а физический адрес файла в FAT.

> В MFT ищется файл-рекорд

Вы определитесь о какой файловой системе говорите :)

← →
Riply © (2007-12-18 16:27) [23]

> [22] guav © (18.12.07 16:25)
> Вы определитесь о какой файловой системе говорите :)

:)

← →
Riply © (2007-12-18 16:29) [24]

> [21] ProgRAMmer Dimonych © (18.12.07 16:25)
> А для меня ещё раз можно?
> А то я чего-то почувствовал себя полным недоумком. :) Попроще бы...

Есть некая "область" в которой система хранит всю информацию
о файловых объектах. Работа идет именно с ней.

← →
ProgRAMmer Dimonych © (2007-12-18 16:32) [25]

> Riply © (18.12.07 16:29) [24]
> Есть некая "область" в которой система хранит всю информацию
> о файловых объектах. Работа идет именно с ней.

Это понятно. С папками там чего такое? Папки с разными именами - это вложенные или опечатка?

← →
clickmaker © (2007-12-18 16:38) [26]

> [8] niKo (18.12.07 14:54)

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

← →
Riply © (2007-12-18 16:38) [27]

> [25] ProgRAMmer Dimonych © (18.12.07 16:32)
> Это понятно. С папками там чего такое?
> Папки с разными именами - это вложенные или опечатка?

Вложенные. Имена взяты из [14] clickmaker © (18.12.07 15:34)
Sorry, что коряво написала.

> [26] clickmaker © (18.12.07 16:38)
> при многократном произвольном открытии-закрытии файлов,
> тормоза будут больше, чем если бы все файлы лежали в корне
> или хотя бы в одной папке.

На FAT - неправда. Более того, столько файлов система не даст положить в одну папку.

> [26] clickmaker © (18.12.07 16:38)

imho:
Самый лучший способ: хранить в корне каждой директории N объектов.
Где N - максимальное кол-во объектов, при которых соответствующий
файловый рекорд остается резидентным.
Зависит, в том числе, и от длинны имен и много чего.
"Среднее" его значение не вычисляла (будет время попробую),
но очень примерно 8 - 16 объектов

niKo (18.12.07 14:10)
если в корневой дериктории диска 1000 папок, в каждой из них еще 1000, в каждой из которых еще по 1000, в которых по 5-20 файлов

Значит на компьютере лежат исходные коды всей Джавы.
:)

Насколько я помню, windows имела ограничения на количество объектов в самой корневой директории (кажется 255). Но возможно это ограничение только для файловых систем типа FAT16.

> [30] kaif © (18.12.07 18:27)
> Насколько я помню, windows имела ограничения на количество
> объектов в самой корневой директории (кажется 255). Но возможно
> это ограничение только для файловых систем типа FAT16.

Да, FAT12 и FAT16 имеют корневую папку в области зарезервированых кластеров, и её размер ограничен. Хоть этот размер и задаётся в бутсекторе, реально он всегда на 512 записей. Запись - это файл, папка, метка диска или фрагмент длиного имени.

> Значит на компьютере лежат исходные коды всей Джавы.

:)))

>>niKo (18.12.07 14:10)
Вы не банк-клиент пишете? А то есть один такой. В папку с данными пихает несколько сотен папок а в каждой по сотне файлов. Тормоза заметны.

← →
niKo (2007-12-18 21:47) [34]

З.Ы. придется все-таки проверить самому, а то еще больше запутался
хотя больше склоняюсь при явном указании пути к файлу тормозить не будет
кстати может еще подскажут что-то ОС Windows Fat32 или Ntfs

> niKo (18.12.07 21:47) [34]
> З.Ы. придется все-таки проверить самому, а то еще больше запутался
> хотя больше склоняюсь при явном указании пути к файлу тормозить не
> будет кстати может еще подскажут что-то ОС Windows Fat32 или Ntfs

А теперь по-русски, пожалуйста. Со знаками препинания, всеми союзами и союзными словами, так, чтобы без телепаии было понятно, о чём вопрос. а то уж больно напоминает дамп ОЗУ человека: месиво.

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

> [34] niKo (18.12.07 21:47)
> З.Ы. придется все-таки проверить самому

Я бы не взяла на себя смелость утвердать, что после
подобного экспиремента удасться привести MFT в прежнее
состояние, даже с помощью дефрагментации :)

> [34] niKo (18.12.07 21:47)

> хотя больше склоняюсь при явном указании пути к файлу тормозить
> не будет

Не понятно.
Утончи что есть "явное" и что есть "неявное" указание.

> кстати может еще подскажут что-то ОС Windows Fat32 или Ntfs

Вопрос не совсем понятен. Если вопрос о том, что лучше выбрать, Fat32 или Ntfs, то тут Ntfsовское индексирование рулит.

> [37] Riply © (18.12.07 23:05)
> Я бы не взяла на себя смелость утвердать, что после
> подобного экспиремента удасться привести MFT в прежнее
> состояние, даже с помощью дефрагментации :)

Есть дефрагментаторы, которые смогут. Стандартный не умеет работать с MFT (вроде FSCTL_MOVE_FILE для $Mft вообще не реализован). Для восстановления MFT стандартными средстваим можно воспользоватся средством "форматирование диска" :)

> [38] guav © (18.12.07 23:56)
> Есть дефрагментаторы, которые смогут. Стандартный не умеет работать с MFT
> (вроде FSCTL_MOVE_FILE для $Mft вообще не реализован). Для восстановления MFT
> стандартными средстваим можно воспользоватся средством "форматирование диска" :)

Ткни мне пальцем в того кто посмеет спорить с таким универсальным средством,
как "форматирование диска" :)

только не предлагайте проверить Найти похожие ветки