Свежие комментарии

Что-то меня переклинило и я взял в голове за систему - маленький объем оперативной памяти и быстрый своп :\

> думаю, что "почти работает" там не лучше, чем ZFS был
Ну Btrfs я в том смысле упомянул, что вряд-ли в Linux будет ZFS, поскольку там именно Btrfs позиционируется в эту нишу.

Re: > Будет и на вашей улице праздник
Я вот думаю, что "почти работает" там не лучше, чем ZFS был последние несколько лет. Только gjournal-ом и спасались последние несколько лет

> Будет и на вашей улице праздник
Я щщщитаю лучше party вчера и сегодня, чем celebration непойми когда. :-) Тем паче, что celebration весьма спорный и пример с FreeBSD это доказывает. Ради ZFS ползти на Solaris? Чёт не хочется. BtrFS, кстати, уже почти работает, но в реальности пока хватает тех же EXT{4,3}, XFS, Reiser

Re: > Масло масляное получается.
128 гигабайт памяти стоят примерно 4 килобакса сейчас (в 10 раз дороже SSD), по 250 за 8-гиговый ECC DIMM.

На этом фоне можно и материнку нормальную купить, которая эту память примет, это недорого.

> то никакой SSD не спасет.
Бывают разные ситуации. Например такие, когда система прошвыривает через своп несколько десятков гигов, а потом всё нормально снова; в случае с SSD это произойдёт существенно быстрее

> казалось бы делаем один ZFS
uname Linux, какая ZFS? Тут LVM-2 и co.

Re: > правильный журнал пишется линейно
Ну казалось бы делаем один ZFS pool на все FS, соответственно один журнал.

> да и throughput тож.
[тут, ес-но, его увеличение имелось в виду. :-)]

> по идее ему скорость позиционирования в штатных
Дело в том, что помимо журнала пишутся и сами данные, причём даже не столько мета- , сколько данные per se , изначальные так сказать. Поэтому журнал на отдельном ус-все штука несомненно полезная для уменьшения latency, да и throughput тож.

Re: > Масло масляное получается.
Я вот сильно не уверен. Свап - дело такое, да вытеснить туда всякие getty ненужные полезно, но откуда в 2009-м году активный свап?

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

Там цена сильно другая.

А для домашнего использования не нужен быстрый терабайт, нужно гигабайт 200-300, цена уже вполне разумная для дома.

>>Потому как объемы будут расти, гигабайт - дешеветь,
К сожалению _пока_ не всё так радостно:
http://www.fclab.ru/2009/10/09/698/

> Масло масляное получается.
Тем не менее, смысл есть засунуть 120 GiB DRAMM в обычную сис. плату не удастся, очевидно [сколько будет стоит 120 GiB DRAMM + настолько необычная сис. плата надо считать :-)]. Так что пусть свопится/пэйджится , несмотря на overhead всё-равно выигрыш в производительности будет

P. S. SSD, для своей Linux-системы, я бы раздал на раздел подкачки и журналы от журналируемых FS'ок [если бы ограничений по r/w-циклам не испугался ;-)].