On Tue, Jan 29, 2013 at 03:40:14PM +0100, Jan Kara wrote: > > As we know the block to be freed can not be superblock and GDT.. > > I don't see any check about it in ext2/ext3/ext4.... > Yes, you are right we apparently don't check for superblock or GDT > blocks. But checking for those will be a bit more complex and they are > really scarce so I don't think it's worth the overhead. We actually do have code to test for that in ext4. Take a look at fs/ext4/block_validity.c. We normally only check to make sure the data block is within the file system bounds, but if you mount the file system with the block_validity, it will actually check to make sure the block being allocated or freed is not part of the superblock, GDT, allocation bitmaps, or inode table. I use this mount option when running my xfstests, just to add an additional level of checking. It's not enabled by default, since it does increase CPU usage. I suspect it would only be visible for benchmarks such as TPC-C, but it's not something we've actually measured to see if we could afford to enable by default. The other major short coming is that we don't update the system zone after an online resize, which means we don't protect the newly metadata blocks until the next time the file system is mounted. If we added updating after a online resize, we'd also have to add some kind of locking to protect the rbtree while it is being changed, and this would increase its overhead if people wanted to use it in production. We might be able to use RCU to avoid doing a real hard lock, but it's not something that I've considered high priority. If someone wanted to look at this, it would actually be a pretty good starter project for someone who wanted to get started with doing ext4 hacking. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
