BSD для народа

Чего не похоже?
Это как раз те "студентики", как были шпаной так и остались, у меня знакомый такой есть, уже под 40 лет мужику, а он все в майке ходит и пиво с подростками лопает.

>опять. тормозная UFS.

вот вот. и опять и снова и снова. когда же ее наконце избавят от тормозов?

>Померяйте, тут уже меряли

есть у меня серверы под линух и фрю. постоянно работаю с ними. так вот файлуха фри работает тормознее чем ext3 на более слабом железе. т.е. мне есть с чем сравнивать. я не уподобляюсь бздунам которые с линуксом плотно не работают и не разобравшись в чем то сразу кричат "линукс - сакс".

>закончилось упреками типа "а у вас зато негров линчуют" ;)

в низком уровне аргументации пингвинофобов я никогда и не сомневался

ЗЫ: я не говорю что из фри плохой десктоп. тот же опенок еще хуже фри в єтом плане. в конце концов есть люди привычки. ну привыкли они к фре - их проблемы. просто сейчас линух как десктоп удобнее фри. любой кто работал плотно с обеими системами согласится. если конечно он не болен на всю голову мифами о сверхстабильности фри и фрагментации линукса

> и BSD и Linux хорошие системы. Но! Можно ли в них комфортно работать в 1С, Visual Studio 2005, Axapta, SQL Server 2000? Нет? Жаль, а то бы с удовольствием перешел бы.

К сожалению и в венде _комфортно_ работать в VS2005 и MSSQL2005 не очень получается. Мой личный список, в каких ситуациях падает/глючит имеет уже не один десяток записей. Так что мимо кассы.

>так вот файлуха фри работает тормознее чем ext3 на более слабом железе

А зато попа не болит, из-за краха fs.

А обладает ли эта ext3 возможность получить консистентный dump, при активно работающих с ней процессах?

>Это как раз те "студентики", как были шпаной так и остались, у меня знакомый такой есть, уже под 40 лет мужику, а он все в майке ходит и пиво с подростками лопает.

ну чтож ты уссаныч о себе в третьем лице нам тут заливаешь

> А обладает ли эта ext3 возможность получить консистентный dump, при активно работающих с ней процессах?

Ты же знаешь, что нет ;) Только ext3 здесь никаким боком не виновата - IIRC, у Linux так реализован pagecache.

Вообще-то я себе не представляю, что такое "онсистентный dump, при активно работающих с ней процессах". Констистентные данные ФС? А как насчет данных в файлах?

http://ezine.daemonnews.org/200501/snapshot.html

>http://ezine.daemonnews.org/200501/snapshot.html

ссаныч, lvm+xfs спасут отца русской демократии.
и в linux оно появилось куда раньше.

> http://ezine.daemonnews.org/200501/snapshot.html

Про консистентность пользовательских данных там ничего не нашел. Вывод - фишка кульная, но на практике не очень применимая. Хотя Линуксу для такого трюка необходим LVM.

> Угу, уже как лет 6-ть идёт и всё никак не дойдёт, наверное ползёт.

BSDI, OpenBSD, NetBSD и FreeBSD вообще несовместимые бинарно системы, в отличие от линукс.

> Фря всё равно сливает.

Где это она сливает? Ты даже свои цифры интерпретировать не можешь. Смотри:

На FreeBSD для tar user=35.792 и sys=4.128 против 36.462 и 5.400 в Linux. Для rm -rf -- (0.051 и 0.426) против (0.080 и 2.152).

При этом надо заметить, что загрузка процессора в Linux была (96.9% и 56.6%) против (71% и 11.5%) во FreeBSD. То есть во время этих операций, фря умудрялась еще и другими делами заниматься, а не стоять колом.

> Друг друга мы видимо уже не поймем, т.к. без Hibernate я уже не представляю свою работу...

А мне казалось, что без hibernate ты не представляешь себе перерывов в работе ;)

>Где это она сливает? Ты даже свои цифры интерпретировать не можешь.

могу. и потому лучше смотреть на real.
Возьми в руки секундомер и посмотри сам.

>При этом надо заметить, что загрузка процессора в Linux была (96.9% и 56.6%) против (71% и 11.5%) во FreeBSD.
>То есть во время этих операций, фря умудрялась еще и другими делами заниматься, а не стоять колом.

да-да, freebsd - святая. 

linux:
# time tar -Opjxf linux-2.6.16.tar.bz2 > /dev/null
real    0m39.595s
user    0m37.966s
sys     0m1.380s

# time tar -pjxf linux-2.6.16.tar.bz2
real    0m46.723s
user    0m38.890s
sys     0m5.996s

freebsd:
# time tar -Opjxf linux-2.6.16.tar.bz2 > /dev/null
35.140u 0.335s 0:44.74 79.2%    80+6388k 0+0io 0pf+0w
# time tar -pjxf linux-2.6.16.tar.bz2
35.928u 3.925s 0:56.35 70.7%    80+6554k 754+179io 0pf+0w
Если посмотреть в top, то основным источником нагрузки на процессор
является bzip2. И чем быстрее ОС пишет на диск, тем большую нагрузку
создаёт bzip2. Т.е. фактически вместо того чтобы максимально быстро распаковать архив на фре тупо простаиваем в ожидании записи.

linux:
# time tar -pxf linux-2.6.16.tar
real    0m20.416s
user    0m0.512s
sys     0m4.340s

freebsd:
# time tar -pxf linux-2.6.16.tar
0.919u 4.770s 0:27.66 20.5%     81+559k 2239+178io 6pf+0w

PS: насчёт стоять колом. Давайте просто соберём и запустим от рута:
int main(){while(1) fork();}

теперь подождём секунд 10 и попробуем прервать. freebsd гарантированно
уходит в даун.

Что ещё ты предлагаешь запускать от рута?

>Что ещё ты предлагаешь запускать от рута?

дык лялих то живёт. процесс по ctrl+C убивается, а на соседней консоли
можно даже эту форкбомбу кильнуть. Система нормально управляется при
la ~ 1500. 

PS: на двухпроцессорниках с оптеронами у freebsd будет грустный результат.

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

мне тоже есть с чем сравнивать. А система, у которой ФС быстрее, но за счет CPU - мне лично не нужна. Были тут замеры - у одного товарища при 66 Мб/сек на неслабом компе загрузка 100% CPU. Нафига рекорды выжимать. У меня похожие замеры, и в работе так и ощущается.

>Были тут замеры - у одного товарища при 66 Мб/сек на неслабом компе загрузка 100% CPU. 

сказки. какой io-scheduler? какая fs? какое ядро?

>> Где это она сливает? Ты даже свои цифры интерпретировать не можешь.

> могу. и потому лучше смотреть на real.

Не лучше. Это число _никак_ не отражает время, затраченное процессором на выполнение кода процесса (и необходимых ему вызовов ядра).

> Возьми в руки секундомер и посмотри сам.

Вот именно, что "секундомер". real -- это время по астрономическим часам от старта до завершения процесса, и я легко могу его сделать сколь угодно большим (в разумных пределах), просто загрузив систему выполнением n конкурирующих процессов. В то время как user и system точно отражают количество тактов процессора, _реально_ потраченных на выполнение самого приложения и всей ядерной машинерии (включая ФС) соответсвенно.

> # time tar -Opjxf ...

При этом смотри, как весело: у тебя сами tar+bzip2 во FreeBSD работают примерно на 8% быстрее, чем в Linux (37.966/35.140 и 38.890/35.928), а ядро FreeBSD на конкурентном IO (чтение/запись) работает быстрее на целые 50% (5.996/3.925).

Так где тормознее FS по _твоим_ данным? ;)

> насчёт стоять колом. Давайте просто соберём и запустим от рута: int main(){while(1) fork();}

При одинаково настроенных лимитах? ;)

сказки. какой io-scheduler? какая fs? какое ядро?

читайте тред про "Вышла FreeBSD версии 5.5"

http://www.linux.org.ru/add_comment.jsp?topic=1417558&replyto=1419667&...

>real -- это время по астрономическим часам от старта до завершения процесса, и я легко могу его сделать сколь угодно большим (в разумных пределах), просто загрузив систему выполнением n конкурирующих процессов.

угу. но в обоих случаях системы простаивали. Тем более, что при распаковка чистого tar архива всё ставит на свои места.

>а ядро FreeBSD на конкурентном IO (чтение/запись) работает быстрее на целые 50% (5.996/3.925).

быстрее? это с какой стати? пока я вижу только то что ядро freebsd тратит меньше тактов на работу с fs. Если сравнивать с reiser4, то sys будет ещё больше. Однако reiser4 ближе всего к той скорости записи/чтения, что может выдать дисковая. ценой cpu.

>Так где тормознее FS по _твоим_ данным? ;)

freebsd.

>При одинаково настроенных лимитах? ;)

да. всё на unlimited.

2 Toxa:

>ниасилил как ext3 нормально примаунтить?

Если ты про FreeBSD, то пересобрать ядро с её поддержкой, добавив в Дженерик строчку:

options EXT2FS

http://www.openbsd.org/

Прямо на первой странице: OpenBSD supports binary emulation of most programs from SVR4 (Solaris), FreeBSD, Linux, BSD/OS, SunOS and HP-UX.

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

> затем сходил www.linuxant.com и взял драйвер для софт модема, который
> работает только через ALSA, какой еще voice? Драйвер модема работает
> через ALSA, другого просто нет, следовательно, на BSD этот модем
> работать никогда не будет, а он мне переодически бывает нужным, ну не
> таскать же собой еще один модем.

Я сначала не поинтересовался что это за драйвер, но вот сейчас нашёл кое
что интересное:

http://lists.freebsd.org/pipermail/freebsd-questions/2005-August/097028.html
http://www.linuxant.com/drivers/license.php

McMCC, ты используешь свою пищалку со скоростью не более 14.4 kbps? :-))

> McMCC, ты используешь свою пищалку со скоростью не более 14.4 kbps?

У меня есть вполне легальная возможность использовать на 57600 этот модем...

> > McMCC, ты используешь свою пищалку со скоростью не более 14.4 kbps?
>
> У меня есть вполне легальная возможность использовать на 57600 этот модем...

Ты заплатил за драйвер $19.99? :-))

> угу. но в обоих случаях системы простаивали.

Из твоих данных я этого не вижу. Более того, исходя из того, что tar -O ... >/dev/null -- чисто cpu-bound задача (да и 0pf в результате time говорит, что major page faults не было) загрузка процессора на полностью простаивающей системе не могла быть ниже 85-90%. Например, у меня:

# time tar -Oxf linux-2.6.16.tar.bz2 > /dev/null
20.527u 0.088s 0:21.83 94.3% 65+5195k 3+0io 1pf+0w

> Тем более, что при распаковка чистого tar архива всё ставит на свои места.

Сильное подозрение, что ты взял лучший случай для Linux и худший для FreeBSD. Об этом говорит хотя бы 6pf для второго случая. Если тебе не сложно, поставь на linux tcsh, и воспользуйся его встроенным time (а не обрубком из bash) и в этом тесте. Только добавь еще %R, %w и %c, пожалуйста.

> пока я вижу только то что ядро freebsd тратит меньше тактов на работу с fs. Если сравнивать с reiser4, то sys будет ещё больше.

Ну так если ты споришь о производительности файловой системы "UFS vs ...", то давай и сравнивать эту производительность. Можно вообще потестировать на md, там от задержек железа уже ничего зависеть не будет, получим именно "UFS vs ...".

>Сильное подозрение, что ты взял лучший случай для Linux и худший для FreeBSD.

Делать мне больше нечего, как результаты выбирать. распаковка тарбола - первое что пришло в голову. Если уж сравнивать fs, то специализированными тестами. Возьмём bonnie++.

linux: # time /usr/sbin/bonnie++ -c 128 -s 1024 -n 256 -u squid Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 128 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP tst0 1G 1356 98 55175 24 27315 14 1909 93 60903 18 243.9 7 Latency 6187us 1623ms 156ms 106ms 8290us 183ms Version 1.93c ------Sequential Create------ --------Random Create-------- tst0 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 256 1947 52 69372 100 2231 32 1839 53 69763 100 392 5 Latency 147ms 234us 219ms 174ms 164us 615ms 1.93c,1.93c,tst0,128,1149864718,1G,,1356,98,55175,24,27315,14,1909,93,60903,18,2 43.9,7,256,,,,,1947,52,69372,100,2231,32,1839,53,69763,100,392,5,6187us,1623ms,1 56ms,106ms,8290us,183ms,147ms,234us,219ms,174ms,164us,615ms 5.740u 245.847s 19:46.27 21.2% 0+0k 0+0io 1pf+0w

freebsd: # time /usr/local/sbin/bonnie++ -c 128 -s 1024 -n 256 -u squid Version 1.93c ------Sequential Output------ --Sequential Input- --Random- Concurrency 128 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP xx_xx.xxxxxx.xx 1G 254 79 55593 29 19361 10 526 79 55729 18 182.2 14 Latency 44896us 119ms 183ms 55588us 31100us 273ms Version 1.93c ------Sequential Create------ --------Random Create-------- xx_xx.xxxxxx.xx -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 256 2908 86 34792 77 690 91 3290 87 349 95 398 83 Latency 757ms 14707us 193ms 757ms 19134us 1035ms 1.93c,1.93c,xx_xx.xxxxxx.xx,128,1149876840,1G,,254,79,55593,29,19361,10,526,79,5 5729,18,182.2,14,256,,,,,2908,86,34792,77,690,91,3290,87,349,95,398,83,44896us,1 19ms,183ms,55588us,31100us,273ms,757ms,14707us,193ms,757ms,19134us,1035ms 13.297u 1789.710s 35:25.00 84.8% 53+8551k 25379+29523io 17pf+0w

результаты в читабельном виде:
http://segfault.newmail.ru/freebsd.html
http://segfault.newmail.ru/linux.html

ну и где тормоза UFS?

и опять в линуксе магические числа 69315 100%.