Здравствуйте, Vetal_ca, Вы писали:

V_>Нашел в закладках

Автор: Cyberax
Дата: 08.08.09

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

Как известно, ядро WinNT было содрано с VAX VMS, где не было слоя виртуальных файловых систем.

В то время как WinNT вышел сразу с виртуальной файловой системой.

Но Microsoft в своей бесконечной мудрости решили пойти своим путём и построить файловую систему на основе модели слоёных драйверов.

Хоть калачом назови, только в печь не клади. ))
Разумеется, виртуальность FS обеспечивается соотв. драйверами, что в Windows, что в Linux, что везде.

Построили. Не работает. Точнее работает очень медленно — в сотни раз медленнее по сравнению с Novell NetWare.

Откровенная ложь.
У нас в лабе в 1994-м были файловые серваки NetWare и Windows NT.
Разница быстродействия составляла менее двух раз.

Напомню, что NetWare использовала кооперативную многозадачность, была незащищённой, дырявой как голландский сыр.
Данные по сети могли могли потеряться, сетевые файлы портились при неудачном одновременном доступе.

В отличие от, NT была тру-многозадачной, хорошо защищённой системой, с корректным одновременным доступом к файлам по сети, с журналированной файловой системой + инструментами для восстановления.

Это были разные весовые категории.

Это как сравнивать быстродействие FoxPro и Oracle на той же самой технике.
Первый надирал задницу второму в простейших сценариях, выглядел бледно в более сложных и совсем сдувался, когда речь заходила об огромном кол-ве сценариев и требований, которые в FoxPro тупо не реализованы.

Еще был файловой сервак с каким-то из юнихов (не помню точно что за юниха, но на иксы я впервые посмотрел именно тогда) — показывали наихудшее быстродействие из всей троицы.
Да и вообще на той же технике юниха знатно тормозили, хотя на меня произвело впечатление работа удалённого текстового терминала, вот там всё просто "летало" по меркам того времени.

Назвали это Fast I/O.
Но так как заглянуть как это сделано в НОРМАЛЬНЫХ системах ума у них не хватило, то для реализации Fast I/O драйверу ФС приходится напрямую взаимодействовать с менеджером кэша.

Нет, не это.
Была разработана концепция настраиваемого кеширования/синхронизации данных в зависимости от особенностей устройства FS.
Разумеется, в такой системе некоторые вызовы "прошивают" слой кеша насквозь, и?
Зато появляется шанс развивать алгоритмы шедуллинга операций кеширования/синхронизации под разные политики хранения, и они с этим в итоге справились великолепно.

То есть, вместо красивой схемы

Эта "красивая схема" сводит с ума жёсткие диски в простейших сценариях, потому что слишком абстрагированные абстракции всегда слабы.
И, главное, ничего нельзя поделать без тотального пересмотра архитектуры... только переезжать на SSD. ))

Не зря все линуховые облака живут на SSD, а жёсткие диски используют как эдакий "прозрачный бэкап длительного хранения".

Естественно, с переусложнёнными схемами блокировки и семантикой работы.

Тут вообще нубство/непрофессионализм, бо на одноядерных тогдашних машинах блокировки были, считай, бесплатными, т.к. реализовывались не через дорогущий CAS, а через дешевые разрешение/запрещение прерываний с установкой флагов. Плюс отсутствие механизма когерентности м/у ядрами, плюс управление сразу передавалось другому потоку в одноядерной машине.

В общем, блокировки стали тяжелы только в многоядерных системах.
Сайберикса несёт, как обычно. ))

Что вызывает то, что NTFS фрагментируется чуть менее, чем мгновенно — даже в условиях, где этого легко избежать.

Очередное шикарнейшее нубство.
Термин "фрагментация" в NTFS стал означать вовсе не то же самое, что в FAT16/FAT32.

NTFS преднамеренно допускала разбиение данных на относительно круные "островки" — кластеры.
Да-да, именно так, как это происходит в malloc, потому что уплотнять все данные друг к дружке показало себя плохой идеей при активном их CRUD.

И вот свинья, не разобравшись в апельсинах, сравнивает их с желудями.

Fail'ы продолжаются. В NTFS добавили возможность монтирования FS на каталоги и символических ссылок (т.е. reparse points). Казалось бы, ну чего тут можно сделать неправильно, когда даже в Windows уже они были реализованы в Windows Services for Unix? Но Microsoft смог сделать это! Вместо хранения симлинков и информации о монтировании дисков в виде специальных файлов (в их объектной ФС, которая это умеет с рождения!) и реализации их на уровне VFS, они СНОВА были реализованы на уровне конкретных драйверов (http://msdn.microsoft.com/en-us/library/ms794497.aspx) с помощью специальных IOCTL'ей.

Тут опять махровое нубство, бо речь идёт не о символьной ссылке на файл, а об directory junction — эффективнейшей штуке NTFS.

Ну ещё есть очень душевные fail'ы как Change Journal — NTFS умеет писать лог всех изменений. Причём он включается совершенно незаметно для пользователя, и никак понять нельзя, что он работает.

Без комментариев. ))
Сайберикс, конечно, никогда не заботился о потере своего лица, эдакий радикальный пох-ист.

Старый FAT32 уже никуда не годиться. Что сделал MS? Правильно, exFAT — консервативное расширение существующего FATа. Унылое на 100% и точно так же неприспособленное для SSD, как и старый FAT

Опять надо бы без комментариев. ))
В общем, именно из-за отсутствия надобности дефрагментации SSD, FAT64 показал себя максимально подходящим (экономным и шустрым) форматом для флешек, т.е. хранилищ относительно небольшого размера, где не предполагается активная 24х7 работа в режиме CRUD.

И да, в Linux тоже с удовольствием используют этот формат для флешек, ровно по той же причине — потому что NTFS, ext3, ext4 отжирают у флешки лишнее драгоценное пространство под внутренние нужды, где эти внутренние нужны заточены под другие сценарии.

Для сравнения, в Linux'е для работы с flash'ем реализован NilFS — http://www.nilfs.org/en/ , поддерживающий непрерывный snapshotting и другие вкусности

С такимми друзьями линуху никаких врагов не надо.
NilFS не имеет к Linux никакого отношения.
Это независимый формат, который однажды был подержкан в ядре Linux аж в 2009-м, когда флешки уже начинали терять свою актуальность.
Поезд уже ушёл... Надо было раньше...

В деле хранения фото/видео, передачи файлов и т.д. всё больше рулили сети (в т.ч. социальные), мессенжеры, почта и т.д., бо интернет уже был практически всегда и везде.


V_>Очень даже нет. Я припоминаю этот ник. Не помню о чем, но помню, что спор с тобой долгий, бессмысленный и занудный.

Факты любят достоверность, а логические выводы — точность.


V>>Или если не понял написанного — спроси подробности.
V_>Это уж точно нет, я не могу так бездарно "закапывать" свое время.

Звиздеть зато бездарно можешь.
Испортил воздух — и убежал. ))


V_>Пользуйся Windows, раз у тебя диски с ума сходят, раз питончики и гейство тебе спать не дают. Мне то, что, наплевать же.

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

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

Но мы эту цель просрали, не справившись с легаси, не озаботившись заранее этим грузом.
Не оформили наш труд таким образом, чтобы он не протухал от малейших изменений архитектур/платформ/характеристик.

Сколько было написано кода и выкинуто?.. На триллионы долларов... ))
Сколько выкинуть жалко до сих пор, хотя давно пора? — на еще большие суммы.

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

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

Степень коллаборации в деле разработки современного ПО натурально удручает, хотя технических проблем давно никаких нет. Есть психологические проблемы "видения", есть ангажированность, нетерпимость, высокомерие и прочее такое, что к технической стороне дела не имеет никакого отношения.

Здравствуйте, Vetal_ca, Вы писали:

V_>Нашел в закладках

Автор: Cyberax
Дата: 08.08.09

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

Как известно, ядро WinNT было содрано с VAX VMS, где не было слоя виртуальных файловых систем.

В то время как WinNT вышел сразу с виртуальной файловой системой.

Но Microsoft в своей бесконечной мудрости решили пойти своим путём и построить файловую систему на основе модели слоёных драйверов.

Хоть калачом назови, только в печь не клади. ))
Разумеется, виртуальность FS обеспечивается соотв. драйверами, что в Windows, что в Linux, что везде.

Построили. Не работает. Точнее работает очень медленно — в сотни раз медленнее по сравнению с Novell NetWare.

Откровенная ложь.
У нас в лабе в 1994-м были файловые серваки NetWare и Windows NT.
Разница быстродействия составляла менее двух раз.

Напомню, что NetWare использовала кооперативную многозадачность, была незащищённой, дырявой как голландский сыр.
Данные по сети могли могли потеряться, сетевые файлы портились при неудачном одновременном доступе.

В отличие от, NT была тру-многозадачной, хорошо защищённой системой, с корректным одновременным доступом к файлам по сети, с журналированной файловой системой + инструментами для восстановления.

Это были разные весовые категории.

Это как сравнивать быстродействие FoxPro и Oracle на той же самой технике.
Первый надирал задницу второму в простейших сценариях, выглядел бледно в более сложных и совсем сдувался, когда речь заходила об огромном кол-ве сценариев и требований, которые в FoxPro тупо не реализованы.

Еще был файловой сервак с каким-то из юнихов (не помню точно что за юниха, но на иксы я впервые посмотрел именно тогда) — показывали наихудшее быстродействие из всей троицы.
Да и вообще на той же технике юниха знатно тормозили, хотя на меня произвело впечатление работа удалённого текстового терминала, вот там всё просто "летало" по меркам того времени.

Назвали это Fast I/O.
Но так как заглянуть как это сделано в НОРМАЛЬНЫХ системах ума у них не хватило, то для реализации Fast I/O драйверу ФС приходится напрямую взаимодействовать с менеджером кэша.

Нет, не это.
Была разработана концепция настраиваемого кеширования/синхронизации данных в зависимости от особенностей устройства FS.
Разумеется, в такой системе некоторые вызовы "прошивают" слой кеша насквозь, и?
Зато появляется шанс развивать алгоритмы шедуллинга операций кеширования/синхронизации под разные политики хранения, и они с этим в итоге справились великолепно.

То есть, вместо красивой схемы

Эта "красивая схема" сводит с ума жёсткие диски в простейших сценариях, потому что слишком абстрагированные абстракции всегда слабы.
И, главное, ничего нельзя поделать без тотального пересмотра архитектуры... только переезжать на SSD. ))

Не зря все линуховые облака живут на SSD, а жёсткие диски используют как эдакий "прозрачный бэкап длительного хранения".

Естественно, с переусложнёнными схемами блокировки и семантикой работы.

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

В общем, блокировки стали тяжелы только в многоядерных системах.
Сайберикса несёт, как обычно. ))

Что вызывает то, что NTFS фрагментируется чуть менее, чем мгновенно — даже в условиях, где этого легко избежать.

Очередное шикарнейшее нубство.
Термин "фрагментация" в NTFS стал означать вовсе не то же самое, что в FAT16/FAT32.

NTFS преднамеренно допускала разбиение данных на относительно круные "островки" — кластеры.
Да-да, именно так, как это происходит в malloc, потому что уплотнять все данные друг к дружке показало себя плохой идеей при активном их CRUD.

И вот свинья, не разобравшись в апельсинах, сравнивает их с желудями.

Fail'ы продолжаются. В NTFS добавили возможность монтирования FS на каталоги и символических ссылок (т.е. reparse points). Казалось бы, ну чего тут можно сделать неправильно, когда даже в Windows уже они были реализованы в Windows Services for Unix? Но Microsoft смог сделать это! Вместо хранения симлинков и информации о монтировании дисков в виде специальных файлов (в их объектной ФС, которая это умеет с рождения!) и реализации их на уровне VFS, они СНОВА были реализованы на уровне конкретных драйверов (http://msdn.microsoft.com/en-us/library/ms794497.aspx) с помощью специальных IOCTL'ей.

Тут опять махровое нубство, бо речь идёт не о символьной ссылке на файл, а об directory junction — эффективнейшей штуке NTFS.

Ну ещё есть очень душевные fail'ы как Change Journal — NTFS умеет писать лог всех изменений. Причём он включается совершенно незаметно для пользователя, и никак понять нельзя, что он работает.

Без комментариев. ))
Сайберикс, конечно, никогда не заботился о потере своего лица, эдакий радикальный пох-ист.

Старый FAT32 уже никуда не годиться. Что сделал MS? Правильно, exFAT — консервативное расширение существующего FATа. Унылое на 100% и точно так же неприспособленное для SSD, как и старый FAT

Опять надо бы без комментариев. ))
В общем, именно из-за отсутствия надобности дефрагментации SSD, FAT64 показал себя максимально подходящим (экономным и шустрым) форматом для флешек, т.е. хранилищ относительно небольшого размера, где не предполагается активная 24х7 работа в режиме CRUD.

И да, в Linux тоже с удовольствием используют этот формат для флешек, ровно по той же причине — потому что NTFS, ext3, ext4 отжирают у флешки лишнее драгоценное пространство под внутренние нужды, где эти внутренние нужны заточены под другие сценарии.

Для сравнения, в Linux'е для работы с flash'ем реализован NilFS — http://www.nilfs.org/en/ , поддерживающий непрерывный snapshotting и другие вкусности

С такимми друзьями линуху никаких врагов не надо.
NilFS не имеет к Linux никакого отношения.
Это независимый формат, который однажды был подержкан в ядре Linux аж в 2009-м, когда флешки уже начинали терять свою актуальность.
Поезд уже ушёл... Надо было раньше...

В деле хранения фото/видео, передачи файлов и т.д. всё больше рулили сети (в т.ч. социальные), мессенжеры, почта и т.д., бо интернет уже был практически всегда и везде.


V_>Очень даже нет. Я припоминаю этот ник. Не помню о чем, но помню, что спор с тобой долгий, бессмысленный и занудный.

Факты любят достоверность, а логические выводы — точность.


V>>Или если не понял написанного — спроси подробности.
V_>Это уж точно нет, я не могу так бездарно "закапывать" свое время.

Звиздеть зато бездарно можешь.
Испортил воздух — и убежал. ))


V_>Пользуйся Windows, раз у тебя диски с ума сходят, раз питончики и гейство тебе спать не дают. Мне то, что, наплевать же.

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

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

Но мы эту цель просрали, не справившись с легаси, не озаботившись заранее этим грузом.
Не оформили наш труд таким образом, чтобы он не протухал от малейших изменений архитектур/платформ/характеристик.

Сколько было написано кода и выкинуто?.. На триллионы долларов... ))
Сколько выкинуть жалко до сих пор, хотя давно пора? — на еще большие суммы.

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

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

Степень коллаборации в деле разработки современного ПО натурально удручает, хотя технических проблем давно никаких нет. Есть психологические проблемы "видения", есть ангажированность, нетерпимость, высокомерие и прочее такое, что к технической стороне дела не имеет никакого отношения.