Re: [PATCH 2/2] Ext3: remove a useless check for the function ext3_free_blocks_sb

[Theodore Ts'o <tytso@mit.edu>]

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