FreeBSD 8.0 Release

> Попробовал в ee набрать комментарий на русском и сохранить (замечу, что локаль у рута везде ru_RU.KOI8-R !!) — русский текст прекрасно сохраняется в UTF-8. Скорее всего, это — заслуга текстового редактора ee.

Многие текстовые редакторы во многих системах могут работать с разными кодировками :-)

Фишка: строки с русскими символами в редакторе ее мигают, а в выводе cat на текстовую консоль — нет. Символы из расширенного набора UTF-8 отображаются НОРМАЛЬНО.

То есть cat сама перекодирует из UTF-8 в кодировку локали? Или что имелось в виду?

>ну и? там же по цифрам ясно видно что ext4 работает быстрее ZFS.

Поначалу — да. :D Со временем Ext4 засирается из-за фрагментации и всё — сливай воду/переформатируй раздел, так как дефрагментатора ещё не разработали.

а про тестирование ext4 vs. UFS2 - никакой инфы по приведенным ссылкам нет.

А ты графики из разных статей сравни: UFS2 процентов на 20 быстрее Ext2 и, соответственно, проигрывает Ext4. Но, учитывая то, что показания тестов UFS2 снимались в 2008 году, и с тех пор много «воды» утекло. В FreeBSD появилась фича объединения страниц в памяти — «super pages» — это заметно сказалось В ТОМ ЧИСЛЕ на дисковых транзакциях.

но, судя по сравнительным тестам UFS2 vs. ZFS (http://alv.me/?p=66), UFS2 громко причмокивая просасывает у ZFS.

Зато UFS2 нетребовательна к оперативке.

Кроме того, в коде VFS FreeBSD 7.2 была улучшена работа механизма совместной блокировки vnode, что повысило производительность ФС, однако эту экспериментальную опцию нужно было включать через sysctl вручную. В FreeBSD 8.0 же эта опция включена по умолчанию (“sysctl vfs.lookup_shared=1“).

Таким образом, UFS2 сейчас по идее заведомо быстрее, чем Ext2 и Ext3. Для сравнения UFS2 с Ext4 и ZFS необходимы новые тесты.

Что именно тестировал Федорчук, только одному ему известно. Дальше комментировать нет смысла.

>То есть cat сама перекодирует из UTF-8 в кодировку локали?

Да. Похоже на это.

>Именно - наступит полный, безоговорочный и окончательный BSD RIP!

Мечтай школьник, мечтай :)))

Вобще, все такие максималисты на ЛОРе, разве все используют экскаватор в своем огороде вместо лопаты? Или пользуются чисто саперной лопаткой, т.к. видишь ли обычная для них RIP?

>> uname -a

FreeBSD rio.fire 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Mon Nov >23 19:22:21 VOLT 2009 root@rio.fire:/usr/obj/usr/src/sys/RIO >amd64

du /boot/kernel/

46M /boot/kernel/

ну-ну... зачем так пугать людей. это со ВСЕМИ модулями. я думаю, врядли, там сетевух больше двух видов найдётся. )

P.S. GENERIC ведро сейчас ~11MB, с кучей вкомпиленых модулей/драйверов. Если пройтись по файлу с конфигом ведра, даже не заморачиваясь, а поотрубав ненужное оборудование, получится ~5MB-5.5MB. У мну щас такое. Никаких проблем не вызывает посмотреть конфиг. Всё нормально описано прям в конфиге, иль в хендбуке.

> так как дефрагментатора ещё не разработали.

в процессе же. скоро допилят. ты сравни по времени, сколько ZFS в продакшне и сколько ext4.

В FreeBSD появилась фича объединения страниц в памяти — «super pages» — это заметно сказалось В ТОМ ЧИСЛЕ на дисковых транзакциях.

это все рассуждения и гадания на кофейной гуще, пока нет конкретных цифр.

Зато UFS2 нетребовательна к оперативке.

можно подумать, ext4 хавает её ведрами..

UFS2 сейчас по идее заведомо быстрее, чем Ext2 и Ext3.

да, потому что ext2/3 тормоза еще те. в ext4 много чего было переделано.

Для сравнения UFS2 с Ext4 и ZFS необходимы новые тесты.

спасибо, кэп! :)

> >То есть cat сама перекодирует из UTF-8 в кодировку локали?

Да. Похоже на это.

Но ведь редактор и cat - не единственные программы, для которых важна кодировка.

Небольшой туториал обновления FreeBSD 7.2 до FreeBSD 8 - http://icpu.ru/?p=157

Ибзден и другие zfs дрочуны - ответьте плиз куда утекают vnodes при простешей операции.

[root@testzfs /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo «sdfsdfsdf» > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes vfs.numvnodes: 860 vfs.numvnodes: 10861

[root@testzfs /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo «sdfsdfsdf» > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes vfs.numvnodes: 10863 vfs.numvnodes: 20863

http://www.freebsd.org/cgi/query-pr.cgi?pr=139715

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

>На той машине, на которой я планирую ставить фряху, иксов нет и не было. За ненадобностью.

Windows dual-boot ? ))))

Поздравляю всех с выходом 8.0!

P.S.: сам пока с 7-ки уходить не хочу.

Сейчас уже стало:

% sysctl vfs.numvnodes
vfs.numvnodes: 19720

Ещё тест:

% bash
[root@rio /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo "sdfsdfsdf" > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes
vfs.numvnodes: 19757
vfs.numvnodes: 29641
[root@rio /tmp]# exit
exit
% sysctl vfs.numvnodes
vfs.numvnodes: 29640
% rm -r /tmp/*
% sysctl vfs.numvnodes
vfs.numvnodes: 19639
% date
вторник, 24 ноября 2009 г. 22:15:56 (VOLT)
% uname -a
FreeBSD rio.fire 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 24 19:31:24 VOLT 2009     root@rio.fire:/usr/obj/usr/src/sys/RIO  amd64

> P.S.: сам пока с 7-ки уходить не хочу.

А я боюсь удаленно обновлять 7.2 до 8.0 =)

Продолжаем сношать vnodes после перезагрузки:

% date
вторник, 24 ноября 2009 г. 22:33:29 (VOLT)
% cd /tmp
% bash
[root@rio /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo "sdfsdfsdf" > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes
vfs.numvnodes: 2376
vfs.numvnodes: 12376
[root@rio /tmp]# exit
exit
% sysctl vfs.numvnodes
vfs.numvnodes: 12376
% rm -r /tmp/*
% sysctl vfs.numvnodes
vfs.numvnodes: 2375
% uname -a
FreeBSD rio.fire 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Tue Nov 24 19:31:24 VOLT 2009     root@rio.fire:/usr/obj/usr/src/sys/RIO  amd64

[root@rio /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo "sdfsdfsdf" > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes
vfs.numvnodes: 23185
vfs.numvnodes: 26010
[root@rio /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo "sdfsdfsdf" > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes
vfs.numvnodes: 25950
vfs.numvnodes: 25951
[root@rio /tmp]# sysctl vfs.numvnodes ; i=1 ; while [ $i -le 10000 ] ; do echo "sdfsdfsdf" > `mktemp -t ABC` ; i=$(($i+1)) ; done ; sysctl vfs.numvnodes
vfs.numvnodes: 25950
vfs.numvnodes: 25938
[root@rio /tmp]# rm -r /tmp/*
bash: /bin/rm: Argument list too long
[root@rio /tmp]# exit
exit
% sysctl vfs.numvnodes
vfs.numvnodes: 25927
% rm -r /tmp/*
/bin/rm: Argument list too long.
% rm -rf /tmp/ABC.*
/bin/rm: Argument list too long.

И как херню из /tmp удалить?

очевидно - find . -exec rm {} \; 8)

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

Ба! Это только теперь появились в бзде! Как же они до того жили? А еще трындели, что бздя заточена под роутер.

Как же они до того жили?

Жили макросами со списками сетей в PF. Теперь и для IPFW счастья привалило.

очевидно - find . -exec rm {} \; 8)

Больше такое никому не показывай.

Я хотел было удалить ФС /tmp совсем, чтобы потом новую сделать. Но написало, что ФС занята и не поддаётся «zfs umount» и «zfs destroy» вообще. Дальнейшие беспорядочные действия в X-терминали привели к его зависанию. Вышел из X'ов (закрыл сессию Xfce обычным образом). Зашёл под рутом. Попробовал выполнить те же действия (по отмонтированию /tmp и деструкции ФС), но и они тоже не возымели эффекта. На команде «ls /tmp» текстовая консоль зависла окончательно. Пришлось жать Reset.

После перезагрузки:

% zfs list /tmp
NAME           USED  AVAIL  REFER  MOUNTPOINT
amd64rio/tmp  1,46M  13,4G  1,46M  /tmp
% ls /tmp
total 2
drwxrwxrwt   7 root  wheel     8B 24 ноя 22:56 ./
drwxr-xr-x  20 root  wheel    26B 24 ноя 22:24 ../
drwxrwxrwt   2 root  wheel     3B 24 ноя 22:56 .ICE-unix/
-r--r--r--   1 root  wheel    11B 24 ноя 22:54 .X0-lock
drwxrwxrwt   2 root  wheel     3B 24 ноя 22:54 .X11-unix/
drwxrwxrwt   2 root  wheel     2B 24 ноя 22:54 .XIM-unix/
drwxrwxrwt   2 root  wheel     2B 24 ноя 22:54 .font-unix/
drwx------   2 igor  wheel     3B 24 ноя 22:56 fam-igor/
%

% zpool status amd64rio
  pool: amd64rio
 state: ONLINE
 scrub: scrub in progress for 0h16m, 5,81% done, 4h33m to go
config:

	NAME              STATE     READ WRITE CKSUM
	amd64rio          ONLINE       0     0     0
	  mirror          ONLINE       0     0     0
	    gpt/rio_zfs2  ONLINE       0     0     0
	    gpt/rio_zfs1  ONLINE       0     0     0

errors: No known data errors

Прогресс:

% zpool status amd64rio
  pool: amd64rio
 state: ONLINE
 scrub: scrub in progress for 0h24m, 14,05% done, 2h30m to go
config:

	NAME              STATE     READ WRITE CKSUM
	amd64rio          ONLINE       0     0     0
	  mirror          ONLINE       0     0     0
	    gpt/rio_zfs2  ONLINE       0     0     0
	    gpt/rio_zfs1  ONLINE       0     0     0

errors: No known data errors

очевидно - find . -exec rm {} \; 8)

без xargs???

> Я хотел было удалить ФС /tmp совсем, чтобы потом новую сделать.

Зачем???

>А сколько там весит ядро?

uname -a

FreeBSD rio.fire 8.0-PRERELEASE FreeBSD 8.0-PRERELEASE #0: Mon Nov 23 19:22:21 VOLT 2009 root@rio.fire:/usr/obj/usr/src/sys/RIO amd64

du /boot/kernel/

46M /boot/kernel/

iZEN не пугай людей. Ядро весит максимум 10 метров. Выкинув все ненужное, метров 6-7.

а то ты со всеми модулями посчитал...

Хехехехе - во первых это была шутка. Во фре свой find (есть правда и гнусявый в портах...было по крайней мере). И таки да - можно и без xargs 8)

Зачем???

Да в ней неудаляемой по rm мелкой гадости было на 60 мегабайт.

Те это такой продакшен реди zfs ? Закапывайте!

> И таки да - можно и без xargs

Можно, но извратно, на каждый файл делать exec rm

> Да в ней неудаляемой по rm мелкой гадости было на 60 мегабайт.

Если по rm что-то не удаляется, то это баг фс, насколько я понимаю.

>Если по rm что-то не удаляется, то это баг фс, насколько я понимаю.

если по rm что-то не удалется, это значит слишком много аргументов передается программе rm. Просто есть ограничение на размер аргумента.

это можно исправить.

Вы не поверите... но пашет очень шустро... 8) А если серьёзно: то набирать больше - лениво.

>Зато UFS2 нетребовательна к оперативке.

т.е. во фряхе сейчас одна ФС сливает по скорости, но просит мало ресурсов, а вторая летает, но жрет память как не в себя? круто

> если по rm что-то не удалется, это значит слишком много аргументов передается программе rm. Просто есть ограничение на размер аргумента.

Кто-то не умеет читать, или просто не в курсе что такое xargs?

> Вы не поверите... но пашет очень шустро... 8) А если серьёзно: то набирать больше - лениво.

Поверю, или не поверю — мне нет никакой разницы, может там волшебный find. Но есть общее решение, которое работает везде, через -print0 | xargs -0, и оно обоснованно оптимизировано.

Цитируем anonymous

Кого, тебя что-ли?

хмм... как же вы, дети задолбали людей закапывать, а?

бывало - спать приляжешь, а поутру приходится гроб ломать и выкапываться...

> du /boot/kernel/

46M /boot/kernel/

Жостер какой то. Однако вертел я на детородном органе такие размеры едра.

box04-msk# cat /etc/make.conf
CPUTYPE?=nocona
CFLAGS= -O2 -pipe
COPTFLAGS= -O2 -pipe

MODULES_OVERRIDE = em mii acpi pf pflog opensolaris zfs krpc syscons/daemon

PERL_VERSION=5.8.9

box04-msk# du -sh /boot/kernel
6.6M    /boot/kernel

>>>Поверю, или не поверю — мне нет никакой разницы...

К счастью, find'у глубоко начхать на Ваше мнение (как и xargs). На досуге как-нить попробуйте разобраться как же они пашут. Вы удивитесь...8)

clear_tmp_enable=«YES» в /etc/rc.conf тоже очень шустро почикала ненужную мелкую хрень в /tmp.

Размер ядра без отладочной информации, IPv6, KTrace и аудита:

> ls /boot/kernel/kernel
-r-xr-xr-x  1 root  wheel    11M 24 ноя 19:31 /boot/kernel/kernel*

В результате инсульта скончался Джон Биррел (John Birrell), известный разработчик проекта FreeBSD, более 12 лет участвующий в развитии проекта. Среди разработок Джона можно отметить портирование технологии динамической трассировки DTrace, разработку библиотеки libdwarf, портирование FreeBSD на архитектуры DEC Alpha и Sun UltraSPARC-T1 (Niagara), создание многопоточной (pthread) библиотеки libc_r. :(

Размер ядра без отладочной информации, IPv6, KTrace и аудита:

Не, ну мне в принципе не обломно конечно компаративной пенисометрией позаниматься:

box04-msk# ls -l /boot/kernel/kernel 
-r-xr-xr-x  1 root  wheel  4278717 Nov 24 14:11 /boot/kernel/kernel

>Пока весь тред не затролили, DTrace - это хитрая штуковина для отладки, стянутоя из Solaris? Если да, то только за этим можно перебираться на сабж.

Открой для себя systemtap

http://sources.redhat.com/systemtap

> К счастью, find'у глубоко начхать на Ваше мнение ...

Ok

На досуге как-нить попробуйте разобраться как же они пашут. Вы удивитесь...

Ну, давай, тогда, начнём с простого вопроса: find -exec prog не запускает программу на каждый файл? Я прекрасно знаю как работает find -print0|xargs -0, и чем именно он предпочтительнее запуска программы на каждый файл. Вы мне тут намекаете на что-то волшебное, качать исходники find от FreeBSD мне немного лень, но я сильно подозреваю, что там тот же самый вызов (v)fork+exec на каждый файл. Как бы ни был дешёв вызов exec, это всё равно становится большим оверхедом, когда файлов много, а в случае, когда их перечень уже не помещаяется в ограничение длины командной строки, это довольно очевидно, что файлов много.

Если есть более внятные объяснения, то я с радостью послушаю.

>Админ локалхоста чтоль? а ну как сломаются иксы?

А зачем тебе юникод, чтобы починить систему?

Нет, господин тролль.
На столе iMac, под столом безмониторная файлопомойка пока-что под арчем, вот туда и буду ставить фряху, если буду... Windows dualboot давно ушел в небытие, максимум - виртуалю.

Я hal не настраивал, по идее он ничего сам не монтирует. Бага

т.е. во фряхе сейчас одна ФС сливает по скорости, но просит мало ресурсов, а вторая летает, но жрет память как не в себя? круто

Во Фри стандартная UFS2, которая по скорости уделывает «энтерпрайзные» (принятые в Red Hat) Ext2/Ext3; и по киллер-фичам уделывает Ext4. И относительно новая ZFS, которая позиционируется как быстрая, суперустойчивая и расширяемая ФС.

По сути, состояние дел с ФС во Фри как нельзя превосходно по сравнению с «энтерпрайзным» Линуксом и Линуксом для домашней файлопомойки.