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 stored > > in the added 128 bytes and evaluate whether this information can be ignored > > without dangerous consequences for filesystem consistency or user data. > > > > 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 != testing. Until we make this work, patch cannot go into the tree.
pgpfHlW3Qa7Vi.pgp
Description: PGP signature
