Date: Tue, 25 Nov 2008 17:03:42 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Josh Carroll <josh.carroll@gmail.com> Cc: freebsd-fs@freebsd.org, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: ext2 inode size patch - RE: PR kern/124621 Message-ID: <20081125150342.GL2042@deviant.kiev.zoral.com.ua> In-Reply-To: <8cb6106e0811250657q6fdf08b0x1e94f35fd0a7ed4f@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081125150342.GL2042>