С чего лусше начать, потом продолжить и т.д.

[Messiah]

Сообщение от Pitty

С трёхтомника Кнута В)
И позвольте увести разговор немного в другую степь: а Вы знаете такую ФС, где нет фрагментации?
Хотя... работа GC похожа на такую ФС. В) Только это уже всё равно дефрагментатор.

Не дефрагментируемых ФС не существует. Мне кажется вопрос надо поставить немного под другим углом. Какая ФС при одинаковой степени дефрагментации страдает от этого меньше чем другие.

[Pitty]

Сообщение от Messiah

А вот позволю не согласиться. Каталог на NTFS представляет собой файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога-бинарное дерево. Для поиска файла с данным именем в линейном каталоге, таком, как у FAT-а, системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя - выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом - сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента. Вывод - для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева - всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо.

А Вы дочитали процитированную статью до конца? ТАм было чётко написано, что современные (а статья была написана в 2000 году) средства ДОС свели на нет разницу между процессом поиска файлов в каталоге.

Вот уж не знаю почему (не разбирался), но натурные измерения копирования файлов показывают, что на ФАТ32 оно выполняется в среднем на 10-12% быстрее.

[Pitty]

Сообщение от Messiah

Не дефрагментируемых ФС не существует. Мне кажется вопрос надо поставить немного под другим углом. Какая ФС при одинаковой степени дефрагментации страдает от этого меньше чем другие.

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

[Vulzscht]

Сообщение от Pitty

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

www.google.com Вам в помощь
з.ы. а вот фрагментация на одном из моих разделов

vulzscht vulzscht # fsck /dev/sda3 -f
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: 182008/1831424 files (0.1% non-contiguous), 3442589/3662190 blocks

вот поэтому во внимание ее я и не принимаю

[Messiah]

Сообщение от Pitty

Вот уж не знаю почему (не разбирался), но натурные измерения копирования файлов показывают, что на ФАТ32 оно выполняется в среднем на 10-12% быстрее.

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

[Messiah]

Сообщение от Pitty

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

Да тут наверное ссылка бесполезна в какой то мере. Я пробовал и не нашёл исчерпывающего ответа. Для любителей поанализировать, наверное надо погуглить приемлемый для своего понимания материал по ext FAT NTFS, почитать, сесть и сравнить..ИМХ однозначного ответа всё равно не будет. НЕТ идеальных ФС! У каждой свои плюсы и минусы и смотря с какой стороны подойти, то минусы одной, могут стать плюсами другой. ФС надо выбирать из круга решаемых задач с целью получения максимальной пользы и минимальной потери!

[Pitty]

Сообщение от Messiah

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

Тестировал на двух одинаковых разделах по 250 Гигов на рейде. Источником был рам-диск.

[Pitty]

Сообщение от Messiah

Да тут наверное ссылка бесполезна в какой то мере. Я пробовал и не нашёл исчерпывающего ответа. Для любителей поанализировать, наверное надо погуглить приемлемый для своего понимания материал по ext FAT NTFS, почитать, сесть и сравнить..ИМХ однозначного ответа всё равно не будет. НЕТ идеальных ФС! У каждой свои плюсы и минусы и смотря с какой стороны подойти, то минусы одной, могут стать плюсами другой. ФС надо выбирать из круга решаемых задач с целью получения максимальной пользы и минимальной потери!

Последнее предложение абсолютно в точку, как в прочем и остальной пост. В)
И так, мы плавно возвращаемся в русло начатой темы: Начинать лучше с того, что ты хочешь делать, каждый язык хорош для чего-то одного: С++ для ресурсоемких приложений, Паскаль для рапид-программинга, васик - побыстрей выучить (хотя спорно уже сейчас) - C# - вот тут хз, похоже это замут на будущее - имхо CLR будет в будущих версиях винды работать в ядре и работать очень не медленно.

[Messiah]

Сообщение от Pitty

Тестировал на двух одинаковых разделах по 250 Гигов на рейде. Источником был рам-диск.

Извиняюсь, но не показатель. Для чистоты эксперимента должно быть одинаковое количество_одинаковых файлов_задач_операций_циклов конвеера ..нельзя скинуть со счёта специфику работы скази и организацию работы RAID..етс. Но вообще то в этой теме пора ставить точку. Мы с этим копанием уходим в цикл. Я не апологет какой либо ОС или ФС. Исхожу из существующих реалий и круга решаемых задач. Примерно поровну работаю как в винде, так и в линуксе..как на работе, так и дома. Отречься от чего то не пытаюсь, т.к. всё существующее есть объективные реалии и их надо принимать де-факто. Не в тему, но тем не менее бувально как вчера прочёл на каком то форуме. Один виндусятник говорит, что настроил загрузку системы за 28 секунд, другой ему вторит, типо - КАК? Я, мол, как не бился, не смог настроить загрузку меньше чем за 32 секунды! Колись, как сделал! Далее у них следовал 5-ти дневный тред по этому вопросу!! ..мне показалась, что аудитория форума слушала их базар с интересом и благоговением.

[Messiah]

Сообщение от Pitty

Последнее предложение абсолютно в точку, как в прочем и остальной пост. В)
И так, мы плавно возвращаемся в русло начатой темы: Начинать лучше с того, что ты хочешь делать, каждый язык хорош для чего-то одного: С++ для ресурсоемких приложений, Паскаль для рапид-программинга, васик - побыстрей выучить (хотя спорно уже сейчас) - C# - вот тут хз, похоже это замут на будущее - имхо CLR будет в будущих версиях винды работать в ядре и работать очень не медленно.

Мысленно аплодирую!