From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: parkheights.dyndns.org from=seriv@parkheights.dyndns.org; domainkey=neutral (no signature; no policy for parkheights.dyndns.org) X-Virus-Scanned: amavisd-new at localhost Message-ID: <44860D38.4080902@parkheights.dyndns.org> Date: Tue, 06 Jun 2006 19:18:16 -0400 From: Sergey Ivanov User-Agent: Thunderbird 1.5.0.2 (X11/20060502) MIME-Version: 1.0 To: Sisyphus@lists.altlinux.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Subject: [sisyphus] =?koi8-r?b?7sUg0M/SwSDMySDXy8zA3sHU2CByZWlzZXI0INcg?= =?koi8-r?b?a2VybmVsLXN0ZDI2Pw==?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.7 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 23:18:28 -0000 Archived-At: List-Archive: List-Post: По моим личным впечатлениям - вполне пора. Я использую на всех личных компьютерах reiser4 с августа или сентября 2004-го года, как она была объявлена готовой. Я терял до этого данные с reiserfs. То есть, содержимое файлов оказывалось перемешивалось, попадало из одних файлов в другие. И ни раз не терял информации с reiser4, даже смог восстановить всё мне нужное после того как случайно на раздел с reiser4 напустил fsck.ext3 -y. Про выключения питания зависания Х-сервера с последующей аварийной перезагрузкой я уж и не говорю. Меня очень радует, что много мелких файлов на reiser4 занимает гораздо меньше места чем на ext3. Недавно мы на работе тестировали новый (уже выложенный by lakostis@ в Сизифус) релиз reiser4, и он выдержал большую нагрузку лучше чем ext3. Немного подробнее: тестировался SMTP сервер, спул которого был размещён на испытываемой файловой системе. При большой нагрузке это получается самый тяжёлый из тестов для файловой системы из тех что я знаю. Из линуксовских файловых систем эту нагрузку выдерживал пока только ext2/ext3. С остальными - ядро паниковало или появлялись процессы которые невозможно было никаким образом убить, или ещё что-нибудь в этом духе. Из нелинуксовских систем это тестирование выдерживает только Solaris'ная UFS. Так вот, reiser4 отрабоал под этой нагрузкой несколько суток без единого замечания в /var/log/messages. Про скорость работы. Если вам очень важна целостность данных, возможно вы уже монтировали ext3 с data_journal, ну и знаете, что при объёме данных превышающих ёмкость буферов памяти это сказывается на замедлении работы в сотню раз (на массовой записи файлов). Но зато при этом гарантируется не только целостность директорий, но и целостность данных в файлах. reiser4 даёт это с замедлением по сравнению с ext3@ordered меньше чем в четыре раза, оказываясь в 25 - 30 раз скорее чем ext3@data_journal. Если есть желающие - я могу сообщить подробнее методику и результаты тестирования. Ситуация с включением reiser4 в ядро линукса неопределённая. Разработчики ядра утверждают, что они не хотят брать код в котором они не разобрались досконально, а код reiser4 большой и сложный, в том числе с нетривиальной математикой положенной в основание алгоритмов. При этом разработчики ядра высказывали претензии к стилю программирования, и чтобы удовлетворить их требованиям команда Namesys переработала очень существенно весь код, заодно видимо его вычистив и улучшив. Те проблемы которые люди докладывали про новую версию reiser4 оказывались проблемами в алгоритмах планировщика и проявлялись и с другими файловыми системами (ext3). Более того, будучи поддержанной в ядре, эта файловая система может ведь отдельными товарищами желающими дать reiser4 ещё время для дополнительного отстаивания, - просто не использоваться. С уважением, Сергей Иванов.