Та вы что, столько нового узнаю сегодня :) и где он по умолчанию? Или включена в коробку - уже по умолчанию?
amso добавил 24.02.2008 в 01:17
Вообще не понимаю к чему это. В freebsd нет дискового кэширования? Или Вы принудительно свои fs с -o sync монтируете? Тогда снимаю шляпу перед Вашим стремлением к стабильности в ущерб эффективности. Неужели в freebsd нет вызовов sync()/fsync() и там единственный способ сбрасывать дисковые кэши - это их не использовать?
Какое счасьте :)
Lupus, о какой пионерии с пинвинами Вы говорили?
Ну и каша у вас в головах, господа (с)
Хорошо, что про FAT уточнили, а то я уже испугался, что Вам в ufs функции readdir и opendir ни с того ни с сего сообщают размеры файлов, вместо того, чтобы возвращать структуру dirent, а stat почему-то не хочет читать структуры stat. Оказывается, копаем глубже, ладно :)
Аргумен про FAT вообще фееричен.
Я пока не задавал еще вопроса, причем тут reiserfs/reiser4 который в линуксе с боку припеку, и вообще весь его импрувмент основан на вытеснении традиционной линуксовой fs семантики. Но агрумент с FAT'ом меня, сознаюсь, придавил. Вы юниксовые бенчмарки примеряете на способности работать с FAT'ом? Не хотите предложить выкинуть из структур юникрсовых файловых систем такие штуки uid/gid, журнал, екстеншены всякие в виде acl и прочую ботву как не экономное использование носителя? Или хотите предложить таблицу указателей на блоки FS размещать в оперативке, как в случае с FAT, и ощутить все прелести такого подхода на многотерабайтной фс с миллионами файлов?
И все таки - с высоты эксперта по FreeBSD пионеру от линукса(то есть мне) - не хотите объяснить, чем таким в freebsd'шной ufs инод с директорией отличается от инода с файлом, что Вы решили искать размер файла в данных инода директории?
Если это было точно так, ядра писали бы на c++ с обработкой ексепшенов (плюплюсники счас меня съедят) :))
К счастью это не так, и там, и там, мы имеем стабильные, готовые к использованию ОСи, и к счастью, видим стремление разработчиков делать систему более эффективной, иначе бы разработка бы просто замкнулась на одной ветке.
Да оставьте вы Столмана в покое, gcc пишут уже толпы других людей. Вообще, после этого абзаца я бы на Вашем месте добавил бы "тьфу-тьфу" - если для freebsd начнут срочно писать новый компилер, улыбаться от этого никто из предпочитателей freebsd не будет. Никто такого "вдруг" не сделает. А вот то, что бок о бок идет разработка gcc+glibc+kernel это кому в плюс?
Это называется жест доброй воли. Это не заложено в цикл разработки.
Вы вообще понимаете, что написали? "размер файла может явно или не очень явно храниться в разных местах ближе к самому файлу"
Возьмите strace и посмотрите, что оно где смотрит и приведите, если сможете, пример конкретной fs, где вызовы семейства stat() дергают инод директории, где он находится, а не самого файла, чтобы узнать размер этого файла
В рамках топика - да, я уточнил, не актуально. В рамках холив^H^H^H^H^H предметного сравнения - почему нет?
плюс тыщапицот
Кроме надежности есть еще эффективность и гибкость. Была такая замечательная без иронии ОС под названием Novell Netware, стабильная до нельзя, но только потому, что была дубовая до нельзя. И отмечу, что эффективность перед FreeBSD стоит такой же задачей, как и перед любым юниксом - задача любого ядра - максимально эффеткивно использовать ресурсы. Наверняка, Вам было бы жалко было иметь стабильную ОС работающую на 1 cpu, хотя в платформу вкручено 2 cpu?
Я не собирался рассматривать ОСи в плоскости крутизны. Это всего лишь программы, и мне до горы, как обстоят дела в операционной системе, которую я не собираюсь использовать.
Но хотели предметного обсуждения? Давайте обсудим предметно. Цитаты из манифестов - это лирика и не совсем уместная. Лозунги к практике мало имеют отношения.
Что до надежности - и там и там есть ветки в разработке и ветки стабильные. Вы считаете корректным обобщение все freebsd vs все "пингвины"? Ну, тогда у меня нет желания продолжать разговор.
И зря Вы пропустили мой вопрос про компилятор. Вы для сборки ядра freebsd используете ГНУ-шный компилер? Если да - задумайтесь, что значит отставание разработки программы от разработки компилятора.
Про лицензии и энтузиастов - это вообще переворот с ног на голову. Я вполне понимаю выбор BSD разработчиков и понимаю их собственную уверенность в собственном выборе BSD лицензии, но я не понимаю почему их выбор внушает уверенность тем, кто полагается на развитие BSD кода, не имея технических возможностей самим развивать этот код. Например, Juniper - они хоть когда-то делились результатами своим наработок в freebsd ядре? Дистрибутив FreeBSD стал лучше от того, что ядро freebsd очень замечательно работает в их железках? Такая ситуация как раз таки и приводит к тому, что код держится на энтузиастах, а большие компании или не хотят или боятся возвращать свои наработки в комьюнити или делать в них вливания.
FreeBSD замечательная операционная система. Все операционные системы замечательные, даже Виндовс. Только, согласитесь, это не вещи из разряда круто или модно. Это инструмент ремесленника. И "одно дело шпицштихель, и совсем другое — больштихель" (с)
amso добавил 23.02.2008 в 05:12
Гениально. А в каких fs про размер файла нужно спрашивать у директории?
amso добавил 23.02.2008 в 05:35
Поймите, что это не BSD, и здесь вполне могут платить и платят з/п за такую разработку - у компаний есть уверенность, что разработки и их производные останутся в public domain. Вы ведь наверняка пользуетесь community mysql, а не enterprise mysql. Вы удивитесь, но это коммерческая организация, зарабатывающая деньги, которая уже принадлежит еще более коммерческой организации Sun Microsystems. У остальных свои мотивации, education и for fun в том числе. И по-вашему это хуже, чем если есть только комьюнити и оно существует на одних только донейтах и энтузиазме?
Разрешите открыть дискуссию? :)
Можно обсудить состояние скредулеров, реализацию smp и вообще способность ядер одного и второго к масштабированию(особенно сети), разнообразие поддерживаемого железа и вариантов виртуализации.
Объективно состояние дел в freebsd vs linux начало быстро меняться еще с релизов ядра линукс 2.4.1[78] В линуксе раньше появилась реализация smp, с этим и сейчас дело обстоит увереннее. В freebsd это дело тормозилось моделью giant lock, с 5.x начали ее убирать из кода, и вообще фрибсдшники улучшения связанные с этим ждут только в 7.x ветке.
По сети - в freebsd kqueue раньше, чем epoll в линуксе, но тут паритет, можно сказать, состоялся. А вспомним недавний патч от V.Ivanov из яндекса(его кстати таки закоммитили или нет?), улучшающий работу интел'овских карт в freebsd - распараллеливание rx/tx потоков на кол-во cpu - достаточно давно есть в линуксе в -rt патчах. А, хоть это для серверов и не актуально, - каково состояние готовности freebsd ядра к требованиям realtime?
А вот такой вопрос - какой компилер использует freebsd по умочанию?
PS. В голосовании не участвую, подведет система или не подведет - на зависит от популярности дистрибутива.
[offtop]
Задайтесь вопросом - какими каналами в таком случае должен обладать крупный хостер на десятки тысяч клиентов. Вопрос совсем не в том, умеет хостер отмахиваться от ддоса или не умеет. Содействие со стороны хостера безусловно необходимо, но это же очевидно - очень несложно накопить с пару десятков клиентов под "хорошим" ддосом, забить им даже широкие каналы и в итоге будут подставлены все остальные клиенты.
PS. В идеале - ддос нужно давить со стороны "ддос-генерящих" ISP, а не со стороны хостера.
[/offtop]
Я так понял, тут речь была о хттп запросах, а там и картинки и вынесенные css/js, тогда 2 млн вполне получается
да, прошу прощения, не заметил
Только добавьте, что аварийное падение mysql или сервера будет означать потерю данных из memory/heap таблицы
