On Tue, 15 Mar 2005, Jeff Mahoney wrote:
>
> This patch is another take at fixing the race between mount and umount
> resetting the blocksize and causing buffer errors, infinite loops in
> __getblk_slow, and possibly other undiscovered effects.
Ok. I had to go back and look up the original problem, and having looked
at this a bit more, I wonder whether the real problem is not that we do
that silly "set blocksize back to the original one" at umount time in the
first place.
(It happens very indirectly, though the "->kill_sb()" fn pointer, which
ends up doing kill_block_super on a regular block device).
Maybe we should just get rid of it entirely? There's really no point to
it.
Instead, to make things repeatable, we'd always just set the blocksize to
its default value at the first open. We already do that anyway, don't we?
Wouldn't that approach also just fix things? And then the fix would
literally be to just remove the set_blocksize() call in kill_block_super.
At that point, we know that the only people who set the block size are
either
- a first opener
- somebody who got exclusive access (ie a filesystem that sets it at
mount-time)
(Yeah, it's a bit more complex than that one-liner, since somebody would
need to back me up on not being totally tripping on some 'shrooms. But Al
can probably do that trivially)
Or maybe I misunderstood the problem. Jeff?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
