From owner-freebsd-fs@FreeBSD.ORG Tue Nov 25 15:03:49 2008 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 1D86A106564A; Tue, 25 Nov 2008 15:03:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 064248FC18; Tue, 25 Nov 2008 15:03:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1L4zS6-0003Jf-Mg; Tue, 25 Nov 2008 17:03:46 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id mAPF3h0v061835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 17:03:43 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id mAPF3gCF058475; Tue, 25 Nov 2008 17:03:42 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id mAPF3gT3058474; Tue, 25 Nov 2008 17:03:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Nov 2008 17:03:42 +0200 From: Kostik Belousov To: Josh Carroll Message-ID: <20081125150342.GL2042@deviant.kiev.zoral.com.ua> References: <8cb6106e0811241129o642dcf28re4ae177c8ccbaa25@mail.gmail.com> <20081125140601.GH2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250617q5fffb41exe20dfb8314fc4a9d@mail.gmail.com> <20081125142827.GI2042@deviant.kiev.zoral.com.ua> <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ucfHZChuBC0NsER/" Content-Disposition: inline In-Reply-To: <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1L4zS6-0003Jf-Mg 4d2fb6b8ba26568a1f40e41e02a31b2b X-Terabit: YES Cc: freebsd-fs@freebsd.org, FreeBSD Stable Subject: Re: ext2 inode size patch - RE: PR kern/124621 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: Tue, 25 Nov 2008 15:03:49 -0000 --ucfHZChuBC0NsER/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 25, 2008 at 09:57:18AM -0500, Josh Carroll wrote: > > I do not suggest testing. I suggest understand what inode metadata is s= tored > > in the added 128 bytes and evaluate whether this information can be ign= ored > > without dangerous consequences for filesystem consistency or user data. > > >=20 > Well, to be clear I didn't just double the size of the inode table. It > is dynamically determined based on the data structure. I'm not a file > system expert (to call me a novice would probably be stretching it), > so I'm hoping someone more versed can chime in. > > All the code does is query the data structure (specifically, the > s_inode_size field of the structure) and use that value instead of > blindly assuming an inode size of 128. I don't think it's a matter of > what is done with the extra bits, since it's just querying the size of > an already created filesystem. Ok, I describe my concern once more. I do not object against the checking of the inode size. But, if inode size is changed, then some data is added to the inode, that could (and usually does, otherwise why extend it ?) change intrerpetation of the inode. Thus, we need a verification of the fact that simply ignoring added fields does not damage filesystem or cause user data corruption. Verification !=3D testing. Until we make this work, patch cannot go into the tree. --ucfHZChuBC0NsER/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkksE84ACgkQC3+MBN1Mb4iE8gCg1Ue4Be6qJSS+Tj4ewDC1fq2f L1UAoL1dlpbZ1B6N39248Fn7jvVgxYW0 =JVAS -----END PGP SIGNATURE----- --ucfHZChuBC0NsER/--