Re: [PATCH] fs: remove s_old_blocksize from struct super_block

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 3 Dec 2005, Anton Altaparmakov wrote:
> 
> This means we are now back to the old behaviour where fs utilities will 
> behave randomly/unpredictably depending on what fs was mounted (or even 
> was tried to be mounted!) on the device last.  So for example a failing 
> "mount -t auto" will leave the block size set to a random number when all 
> fs utilities (at least used to) asume the block size is 1k and strangeness 
> ensues.

No, an open() with a zero count should re-set the block size to the "best 
possible one". This gives you _consistently_ the blocksize you should get. 
See bd_set_size().

Which is basically the biggest possible one that we can handle that also 
handles the size of the device correctly (if the device has an odd number 
of sectors, you need to set blocksize to just 512).

So things are consistently "optimal", which is the whole point. An opener 
can then set it to some sub-optimal value (which may be bigger and faster, 
but will mean that the last odd sectors can't be reached) by hand if it 
cares.

And of course, if multiple openers exist, there is no consistent value at 
all. It's a bug in user space (and we don't allow that for mounted block 
devices, since the filesystem often _requires_ a particular blocksize).

> I have no idea why Jeff (Mahoney) considered the setting to be 
> unnecessary, when Al Viro added the resetting code a few years ago it 
> was done precisely because utilities were behaving randomly/erratically...

The old code was buggy. It caused both performance problems (lower 
blocksize than necessary when new openers came in, causing really bad 
throughput) and iirc correctness problems (it would stick a 1kB blocksize 
on a device that couldn't then read the last sector, so accessing the 
device with /dev/xyz wouldn't get all the data).

You can still set the blocksize explicitly, but you need to do it AFTER 
you've opened the device exclusively. 

It was a BUG to do anything else (eg set the blocksize at boot and expect 
that the broken blocksize would get restored after others realized they 
needed something else).

Now, it's entirely possible that we've introduced other breakage since, 
but unless you can show a real case, I think you're barking up the wrong 
tree. 

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/