Показать сообщение отдельно
Старый 01.01.2013, 05:37
wvxvw вне форума Посмотреть профиль Отправить личное сообщение для wvxvw Найти все сообщения от wvxvw
  № 149  
wvxvw
Modus ponens
 
Аватар для wvxvw

модератор форума
Регистрация: Jul 2006
Адрес: #1=(list #1#)
Сообщений: 8,049
Записей в блоге: 38
Мы говорим о разных вещах. У файловой системы есть традиционные средства оптимизации поиска нужных блоков на диске. В системах типа FFS, XFS, ext2-ex4 были приняты решения делать его таким, чтобы во многих, или даже во всех случаях сделать возможным чтение (а иногда и запись!) параллельными. А в Macintosh HFS файл, который описывает где находятся i-nod'ы - один, и представляет из себя большое дерево, которое приходится лочить на время, когда система что-то делает с файлами, даже операции, которые в других Юниксах не вызывают таких осложнений.
Макинтошевская файловая система строилась в рассчете на красивый пользовательский интерфейс, и этого никто никогда не сркывал, но она не строилась в рассчете на производительность. Ну, ничего не поделать.
Архивация тут совершенно не показатель, т.как обычно очень сильно напрягает процессор, и это оставляет файловой системе много времени на адаптацию, т.как информация на запись поступает медленно. Чтобы тестировать производительность файловой системы нужно понимать, как она устроена, и какие задачи вы перед ней ставите.

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

Вот тот же поиск о котором вы только что вспомнили - если знать как, и если знать где, то эта задача может оказаться решаемой за категорически разное время на той же системе. К примеру сравните стандартные find и locate - где последняя работает через кешированый индекс, а первая производит тотальный поиск. Но у find есть столько опций конфигурации, что вы можете выстроить планы поиска так, что найти один и тот же файл займет совершенно разное время. В виндовсе тоже нужно знать АПИ, нужно понимать, как файловая система размещает информацию о файлах, и главное, нужно понимать, что именно вы хотите от поиска.
__________________
Hell is the possibility of sanity