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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
