From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 18 Sep 2002 20:19:54 +0400 From: Sergey Vlasov To: Oleg Vladimirovich Subject: Re: [Comm] FS Message-ID: <20020918161954.GA4406@vcserver.mivlgu.internal> Mail-Followup-To: Oleg Vladimirovich References: <1426053284.20020918184511@kdtu.kr.ua> <16591373107.20020918195414@interface.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16591373107.20020918195414@interface.ru> Sender: community-admin@altlinux.ru Errors-To: community-admin@altlinux.ru X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.0.13 Precedence: bulk Reply-To: community@altlinux.ru List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Archived-At: List-Archive: List-Post: On Wed, Sep 18, 2002 at 19:54:14 +0400, olgerd wrote: > Hello Oleg, > > Wednesday, September 18, 2002, 7:45:11 PM, you wrote: > > OV> Приветствую коллектив ! > > OV> Вопрос : чем отличается журналируемая файловая система от > OV> нежурналируемой ? Или где можно почитать на эту тему. > > OV> Буду благодарен за совет. > > > Журналируемая файловая система способна восстановить данные после > незапланированной перезагрузки например, или же после перепада > напряжения. Ничего подобного. Как правило, восстанавливается только целостность метаданных, да и то на некоторый момент времени перед сбоем. На практике это означает следующее: 1. Файлы или каталоги, созданные перед сбоем, могут после восстановления не появиться (если информация об их создании не успела записаться в журнал), т.к. обычно синхронная запись не используется. 2. Целостность собственно данных, хранящихся в файлах, тоже не гарантируется (если только программа не использовала fsync() или подобные вызовы, обеспечивающие физическую запись информации на диск). В частности, для reiserfs характерно следующее поведение. Допустим, в момент сбоя в какой-либо файл дописывались данные в конец (соответственно, длина файла увеличивалась). Тогда зачастую получается, что запись об изменении длины файла и выделении новых блоков данных для него уже попала в журнал и записана на диск, а сами блоки с данными еще не записаны. Если в этот момент происходит сбой, при последующей перезагрузке и восстановлении длина файла увеличивается согласно записи в журнале, в результате чего в конце файла оказывается мусор. Файловая система ext3 поддерживает различные режимы журнализации данных и по умолчанию работает в режиме data=ordered, поэтому такое с ней обычно не происходит (но и работает соответственно медленнее).