The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз Linux-ядра 2.6.34, opennews (??), 17-Май-10, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


32. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от User294 (ok), 17-Май-10, 17:12 
iZEN ты забыл сказать что весь твой UFS2 это - "как бы нам сделать из окаменевшего говна не совсем говно с минимальными изменениями кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

44. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от Аноним (-), 18-Май-10, 06:06 
Вы сейчас глубоко задели всех пользователей BSD систем, которые на "костыльных" UFS держат кучи нагруженных серверов по всему миру, несмотря на свою ущербность в Ваших глазах
Ответить | Правка | Наверх | Cообщить модератору

61. "Релиз Linux-ядра 2.6.34"  –1 +/
Сообщение от User294 (ok), 18-Май-10, 22:46 
А чего такого оскорбительного в констатации фактов? Все познается в сравнении. И UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности. На лично мое имхо такие дизайны свое отжили, по большому счету. Вон в ext4 закопали останки чего-то похожего по смыслу, куда ему и дорога :)
Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от mnu (??), 19-Май-10, 20:55 
>UFS всего лишь ископаемое. С весьма древней организацией и потому понятно какое по производительности.

а ты его тестил? :-) или так, чисто газифицируешь?

Ответить | Правка | Наверх | Cообщить модератору

81. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от User294 (ok), 20-Май-10, 16:55 
>а ты его тестил? :-)

Я не интересуюсь тестами ископаемых. Даже с костылями и подпорками. Это скучно и неперспективно.

>или так, чисто газифицируешь?

Так, чисто на архитектуру посмотрел слегка. Не понял нахрен оно вот такое. Вы поняли? Считаете это отличным инженерным решением? Юзайте наздоровье. А у меня ощущение вида "я его слепила из того что было".

Ответить | Правка | Наверх | Cообщить модератору

52. "Релиз Linux-ядра 2.6.34"  +2 +/
Сообщение от mnu (??), 18-Май-10, 16:25 
> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.

Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW - это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости места на zpool'ах. Из не-production-ready есть HAMMER, по возможностям в некоторых местах превосходящий Btrfs, а в некоторых (сжатие, например) - всё ещё ей уступающий. Но HAMMER пока ещё не настолько стабилен, как UFS. Памяти жрёт меньше, чем ZFS, это да. Отжирает только в момент reblocking'а. Ни HAMMER, ни ZFS простыми не назовёшь. Не назовешь простой так же и XFS с reiserfs (которые в FreeBSD read-only).

При использовании UFS + SUJ при более чем приемлемом быстордействии Вы сохраните оперативную память. При использовании async UFS + geom_journal Вы жертвуете ~1Gb под журнал и имеете производительность, соизмеримую с любой развитой journalled FS (с теми же ограничениями). В обоих случаях Вы не рискуете целостностью Ваших данных, Вам практически наплевать на фрагментацию (в отличии от ZFS) и RAM'ы кушается не много.

А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL... Ну, ускоряет немного благодаря delayed inode allocation, да, но ето не особо важно. Команда DragonFLyBSD вообще наплевала на UFS2, резонно решив, что лучше потратить время на стабилизацию HAMMER'а.

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

57. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от iZEN (ok), 18-Май-10, 18:10 
>> Copy-on-write зарулит нафиг все эти потуги. Хорошие вещи должны быть простыми и не костыльныим.
>
>Хм. Единственная production-ready (tm) FS на *BSD, построенная на технологии CoW -
>это ZFS, жрущая кучу RAM и дико тормозная при 95%+ занятости
>места на zpool'ах.

Про "кучу" RAM и тормоза при 95% занятости можно подробнее?
На днях копировал каталог с музыкой (~120ГБ) с ZFS (стационарный винчестер, SATA-2) на UFS2 (мобильный винчестер, SATA-2). После некоторого момента отожралось 100% RAM и графический пользовательский интерфейс перестал реагировать на кнопки мыши, тем не менее в фоне команда cp копировала файлы и таки закончила это дело. И, да, на ZFS включен prefetch — возможно это как-то повлияло на процесс копирования.

>А UFS2 нужен в основном для ОЧЕНЬ больших (>226Tb) FS да для всяких хитрых ACL...

Всегда считал, что предельный физический размер тома с UFS2 — 2ТБ вследствие ограничений разрядности некоторых value-типов в исходном коде FFS.

Ответить | Правка | Наверх | Cообщить модератору

73. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от Аноним (-), 19-Май-10, 13:42 
mnu@RELENG_8_0:~> dd if=/dev/zero of=/tmp/gvirstor.dd bs=1m oseek=1999 count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.003561 secs (294459461 bytes/sec)
mnu@RELENG_8_0:~> ll -sh /tmp/gvirstor.dd
1072 -rw-r--r--  1 mnu wheel   2,0G 19 тра 12:34 /tmp/gvirstor.dd
mnu@RELENG_8_0:~> s mdconfig -a -f !$ -u 12
s mdconfig -a -f /tmp/gvirstor.dd -u 12
mnu@RELENG_8_0:~> s gvirstor label -v -s 4Tb virtest /dev/md12
Total virtual chunks: 1048576 (4 MB each), 4194304 MB total virtual size.
Clearing metadata on /dev/md12.
Writing allocation table to /dev/md12... (8 MB, 2 chunks)
Storing metadata on /dev/md12 (500 chunks) (4 reserved) Done.
mnu@RELENG_8_0:~> diskinfo -v /dev/virstor/virtest
/dev/virstor/virtest
        512             # sectorsize
        4398046511104   # mediasize in bytes (4.0T)
        8589934592      # mediasize in sectors

mnu@RELENG_8_0:~> s newfs -O2 !$
s newfs -O2 /dev/virstor/virtest
/dev/virstor/virtest: 4194304.0MB (8589934592 sectors) block size 16384, fragment size 2048
        using 22825 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144,
6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776,
.....
etc etc

As for ZFS slowdown, try to download some gigabytes of torrents in parallel to it, especially when zpool is nearly full.

Ответить | Правка | Наверх | Cообщить модератору

74. "Релиз Linux-ядра 2.6.34"  +1 +/
Сообщение от mnu (??), 19-Май-10, 14:17 
after adding some more 8Mb-chunked (yeah i should make chunks smaller, but who cares) MD's to geom_virstor (so newfs can proceed):

mnu@RELENG_8_0:~> s mount /dev/virstor/virtest /mnt/tmp
mnu@RELENG_8_0:~> df !$
df /mnt/tmp
Filesystem           1K-blocks  Used      Avail Capacity  Mounted on
/dev/virstor/virtest 4159842858    4 3827055426     0%    /mnt/tmp
mnu@RELENG_8_0:~> df -h /mnt/tmp
Filesystem              Size    Used   Avail Capacity  Mounted on
/dev/virstor/virtest    3.9T    4.0K    3.6T     0%    /mnt/tmp
mnu@RELENG_8_0:~> gvirstor status
           Name            Status  Components
virstor/virtest  6% physical free  md12
                                   md13
                                   md14
                                   md15
                                   md16
                                   md17
                                   md18
                                   md19
                                   md20
                                   md21
                                   md22
                                   md23
                                   md24
mnu@RELENG_8_0:~> ll -s /tmp/gvirstor.dd /mnt/big/gvirstor* | awksum # space really taken on disks by sparse MDs
1529120
mnu@RELENG_8_0:~> gvirstor list | grep Mediasize | awk '{s += $2} END {print s/1024}'
4395319296
mnu@RELENG_8_0:~> s umount /mnt/tmp
mnu@RELENG_8_0:~> s newfs -O1 /dev/virstor/virtest
/dev/virstor/virtest: 4194304.0MB (8589934592 sectors) block size 16384, fragment size 2048
        using 22834 cylinder groups of 183.69MB, 11756 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
32, 376224, 752416, 1128608, 1504800, 1880992, 2257184, 2633376, 3009568, 3385760,
...
etc etc (there is no delayed inode allocation in UFS1, therefore newfs works MUCH slower this time)

So 4Tb virtual storage is OK for UFS1 too.

p.s. ZFS is used w/o prefetch here, as i do not have 4Gb+ RAM, and benchmarks showed it is faster w/o prefetch.

p.p.s. Another ZFS slowdown (full-blown hard kernel hang for upto 10 sec) will be experienced by "zfs compression=on" users - kernel will hang while zlib compresses data, which is then sent to ZFS. Only then kernel will unhang and continue.

Ответить | Правка | Наверх | Cообщить модератору

55. "Релиз Linux-ядра 2.6.34"  +1 +/
Сообщение от iZEN (ok), 18-Май-10, 17:52 
>iZEN ты забыл сказать что весь твой UFS2 это - "как бы
>нам сделать из окаменевшего говна не совсем говно с минимальными изменениями
>кода поскольку большие делать все-равно некому". В итоге к ископаемому архаику
>прикрутили сомнительных костылей. Офигенная, блин, эволюция. ИМХО Copy-on-write зарулит нафиг все
>эти потуги. Хорошие вещи должны быть простыми и не костыльныим.

То же самое происходило: Ext2 > Ext3 > Ext4. Сюрприз? Вот только ни в одной из них поддержки онлайновых снапшотов нету и нельзя делать проверку структур (fsck) на смонтированной ФС...


Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

59. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от User294 (ok), 18-Май-10, 22:36 
> Вот только ни в одной из них поддержки онлайновых снапшотов нету

Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В случае CoW и подобных по смыслу ФС снапшоты имеют некий физический смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно. А в простой ФС во первых тупо делать то же что уже реализовано а во вторых - общая эффективность создания снапшотов в классической ФС - сами понимате какая. А никакая, блин.

> нельзя делать проверку структур (fsck) на смонтированной ФС...

...что для журналируемой ФС не слишком то актуально ;)

А вот на экстенты в UFS2 как я понимаю так и не перешли, да? А то разница между ext3 и 4 в ряде случаев просто вызывает отпад челюсти.

Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз Linux-ядра 2.6.34"  +1 +/
Сообщение от iZEN (ok), 19-Май-10, 02:31 
>> Вот только ни в одной из них поддержки онлайновых снапшотов нету
>
>Что логично, т.к. LVM есть. Зачем городить повторный функционал в ФС? В
>случае CoW и подобных по смыслу ФС снапшоты имеют некий физический
>смысл, являясь по сути свойством-фичой дизайна ФС и там оно осмысленно.
>А в простой ФС во первых тупо делать то же что
>уже реализовано а во вторых - общая эффективность создания снапшотов в
>классической ФС - сами понимате какая. А никакая, блин.

Для UFS2 и ZFS время создания снапшотов — мгновенное. К тому же, LVM, в отличие от ZFS, не поддерживает инкрементные снимки и клоны.

>> нельзя делать проверку структур (fsck) на смонтированной ФС...
>
>...что для журналируемой ФС не слишком то актуально ;)

Ну, да. Лучше подождать минуту-другую, пока монтируемая ФС проверится, чем двадцать минут насиловать смонтированную рабочую ФС.

>А вот на экстенты в UFS2 как я понимаю так и не
>перешли, да? А то разница между ext3 и 4 в ряде
>случаев просто вызывает отпад челюсти.

Нет, экстенты в UFS2 ещё не реализовали, есть только необходимые структуры для этого. Зато в UFS2 идёт адресация на уровне фрагментов блоков (от 2 до 16 кбайт), чем экономится пространство под файлы и практически нету разбросанных по всему диску полупустых блоков с хвостами файлов, как в случае с Ext2/3. У Ext4 какой минимальный размер блока?

Ответить | Правка | Наверх | Cообщить модератору

75. "Релиз Linux-ядра 2.6.34"  +1 +/
Сообщение от mnu (??), 19-Май-10, 14:29 
>А вот на экстенты в UFS2 как я понимаю так и не перешли, да?

Вы понимаете не правильно.
http://www.freebsd.org/cgi/man.cgi?query=newfs&apropos=0
У UFS2 - переменный размер блока + частичная поддержка екстентов
(для хранения больших файлов + для атрибутов, AFAIK).

>[оверквотинг удален]
>     produce poor results.
>  -d max-extent-size
>     The file system may choose to store large files using extents.
>     This parameter specifies the largest extent size that may be
>     used.  It is presently limited to its default value which is 16
>     times the file system blocksize.
>  -f frag-size
>     The fragment size of the file system in bytes.  It must be a
>     power of two ranging in value between blocksize/8 and blocksize.
>     The default is 2048 bytes.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

76. "Релиз Linux-ядра 2.6.34"  +/
Сообщение от mnu (??), 19-Май-10, 14:31 
гррр, съело цитату.

>  -b block-size
>         The block size of the file system, in bytes.  It must be a power
>         of 2.  The default size is 16384 bytes, and the smallest allow-
>         able size is 4096 bytes.  The optimal block:fragment ratio is
>         8:1.  Other ratios are possible, but are not recommended, and may
>         produce poor results.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру