From owner-freebsd-fs@FreeBSD.ORG Mon Oct 29 17:22:33 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F64F16A41B for ; Mon, 29 Oct 2007 17:22:33 +0000 (UTC) (envelope-from julien.bellanger@capgemini.com) Received: from mxefra01.capgemini.com (mxefra01.capgemini.com [194.11.254.68]) by mx1.freebsd.org (Postfix) with ESMTP id A8DC613C48A for ; Mon, 29 Oct 2007 17:22:16 +0000 (UTC) (envelope-from julien.bellanger@capgemini.com) Received: from mxifra01.capgemini.com (MXIFRA01 [205.223.229.10]) by mxefra01.capgemini.com (8.13.6/8.13.6) with ESMTP id l9TCtDZ5018615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Oct 2007 13:55:13 +0100 (MET) Received: from mxifra01.capgemini.com (localhost [127.0.0.1]) by mxifra01.capgemini.com (8.13.6/8.13.6) with ESMTP id l9TCtBuK007188 for ; Mon, 29 Oct 2007 13:55:11 +0100 (MET) Received: from corpmta13.corp.capgemini.com (corpmta13.corp.capgemini.com [205.223.229.53]) by mxifra01.capgemini.com (8.13.6/8.13.6) with ESMTP id l9TCtBYi007180 for ; Mon, 29 Oct 2007 13:55:11 +0100 (MET) Received: from CORPMAIL31.corp.capgemini.com ([205.223.229.30]) by corpmta13.corp.capgemini.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Oct 2007 13:55:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Oct 2007 13:55:10 +0100 Message-ID: <6B8707EF978E3E4E908642088C6E7011B595EC@CORPMAIL31.corp.capgemini.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problem concerning the UFS consistency with embedded FreeBSD system Thread-Index: AcgaKvBXaKqbU7HIRO6yX8sgNZFk9Q== From: "Bellanger, Julien" To: X-OriginalArrivalTime: 29 Oct 2007 12:55:11.0079 (UTC) FILETIME=[F0CA2F70:01C81A2A] Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem concerning the UFS consistency with embedded FreeBSD system X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2007 17:22:33 -0000 Hi, =20 Summary : After I shut down the power and ran fsck on FS, the Size field of a file that was written during the power cut off is corresponding to the final size of the file to write and not the actual length of the block really written=2E FSCK only corrects he FS block metadata information, not the real file size written=2E =20 =20 I have installed i386 FreeBSD 6=2E2 system on an embedded card (Kontron card)=2E This system is installed in an environment where power is cut off many time a day=2E=20 =20 In that condition, I try to maintain and detect as much as possible the consistency of the FS data flushed on the disk and I discovered a problem concerning the consistency of the SIZE wrote in I-node descriptor with the real BLOCKCOUNT associate to this I-node=2E =20 More precisely if I'm coping 50 files of 10Mb from a directory to another (via the cp command) and cut the power off in the middle of this operation : =20 - on reboot the FSCK program detects the incoherence and prints : /dev/ad2s1f: INCORRECT BLOCK COUNT I=3D5205090 (20160 should be 19360) (CORRECTED) so it corrects the BLOCKCOUNT in the associated I-node 5205090 =20 - The problem is that the fsck doesn't correct the SIZE in this I-node, and the announced size is set to the final waiting size even if fsck has detect the loss of data block=2E=2E=2E (I can saw that with the fsdb= command) =20 - Thus when I remount this File System, the file seems OK with the good size, but If I read it with VI, I actually only read correct data at the start of the file (corresponding to the data block that could be read) and the end of file is filled with bad character (uninitialized data in the extended memory alloc due to the incorrect SIZE file information, I supposed)=2E =20 Is some one able to explain me :=20 - why the SIZE memorized in I-node seems always reflect the final size of the file and not the actual size wrote on disk ? - why FSCK doesn't correct the SIZE metadata in the I-node block ? - how I can detect such inconsistency (FSCK doesn't return an error code in this case) =20 (For your information I have the same problem with a FS where the SoftUpdate option is disabled) =20 In your advice can we consider that as a bug ? In my mind FSCK should be able to set at minima the SIZE equal to BLOCKCOUNT data really wrote=2E =20 =20 Thanks in advances for your answers=2E =20 =20 Julien BELLANGER Capgemini Telecom Media =20 This message contains information that may be privileged or confidential= and is the property of the Capgemini Group=2E It is intended only for the= person to whom it is addressed=2E If you are not the intended recipient, = you are not authorized to read, print, retain, copy, disseminate, = distribute, or use this message or any part thereof=2E If you receive this= message in error, please notify the sender immediately and delete all = copies of this message=2E