From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Real-To: Message-ID: <3F1BB555.2080907@mail15.com> Date: Mon, 21 Jul 2003 13:41:41 +0400 From: "Aleksey Avdeev" User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru-RU; rv:1.4) Gecko/20030710 X-Accept-Language: ru, ru-ru, be, uk, en-us, en MIME-Version: 1.0 To: sisyphus@altlinux.ru Subject: Re: [sisyphus] Re: f**k reiserfs References: <20030714200628.GA2287@bigiron.solutions.lv> <3F1432A0.6060403@hotbox.ru> <20030715172350.GA1561@bigiron.solutions.lv> <3F143E63.80706@hotbox.ru> <20030715193321.GA1893@bigiron.solutions.lv> <3F1474A3.2020405@l14.ru> <20030716180824.GM3593@osdn.org.ua> <3F1654C3.40105@l14.ru> <20030717165728.1b9fcfc2.nikodim@kgrs.kuzbe.elektra.ru> <3F166AEA.2080701@l14.ru> <20030718103843.3c6e1d3b.nikodim@kgrs.kuzbe.elektra.ru> <3F18695E.7080500@l14.ru> <20030721091345.2a6196e0.nikodim@kgrs.kuzbe.elektra.ru> <3F1BA980.20900@l14.ru> In-Reply-To: <3F1BA980.20900@l14.ru> X-Enigmail-Version: 0.76.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: sisyphus@altlinux.ru X-BeenThere: sisyphus@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: solo_oboroten@mail15.com, sisyphus@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2003 09:38:08 -0000 Archived-At: List-Archive: Долго наблюдал за дискуссией... Решил присоединиться. ;-) avl@l14.ru пишет: > nikodim пишет: > ... >> >> > и fat и ext2 несравнимо надежнее ntfs и прочих ЖФС за счет своей > простоты и полного комплекта утилит для восстановления данных в том > числе с форматированных или очищеных носителей. > > > Но в них нет главного - точного подтверждения, того факта, что ФС > действительно не порушена. В этом и состоит миссия журнала - внести > информационную избыточность для проверки непротиворечивости метаданных > и ловли фактов недозаписи данных. Можно увеличивать (и увеличивают) > избыточность журнала и таким образом получать возможность коррекции > ошибок при некоторых видах отказов, но более прямой путь для этого - > раиды. Не надо вешать на ЖФС тот функционал, которого в ней нет и быть > не может. Функционал то навесить несложно... Но вот нужно ли: за всё платить надо. В данном случаи - накладными расходами. Нет принципиальных сложностей (точнее, я их не вижу ;-)) внедрить в ЖФС механизм транзакций в полном объёме... Но накладные расходы при этом - возрастут многократно. (В качестве примера - можно сравнить величину отклика БД с разными настройками журналирования.) Отсюда вопрос: Оно надо, на типичных для ФС задачах? ИМХО: ЖФС - вполне удачный компромис скорость-надёжность для широкого класса задач. Если требуется болие высокая надёжность, а скорость не критична - нужны другие решения. (Например - на основе БД ;-).) -- С уважением. Алексей.