On Friday October 13, [email protected] wrote:
>
> One is the existence of clipped disks. There are various ways of
> making a disk appear smaller than it really is - there may be
> a HPA or DCO or so, or just a capacity-limiting jumper.
> This may mean that the kernel does not really know the size
> of the disk. The jumper may cause IDENTIFY to return a small size
> while actual I/O succeeds beyond that. Or, a SETMAX command is
> needed to make all of a partition available. Etc.
Yes..... but access to the whole device is clipped based on the
kernel's understanding of the size of the device, and allowing code
too by-pass that clipping by using a partition seems just *wrong*.
Presumably a very-privileged BLKSETSIZE64 would be the appropriate
thing for that sort of situation.
If a device claims to be smaller will the low-level driver actually
allow a request to a larger address at all???
>
> One is the numbering of partitions. People are very unhappy
> when something causes their partitions to be renumbered.
> That is an argument against the discarding.
Valid comment. My patch doesn't affect numbering.
Partitions that are beyond the end of the device are not enabled at
all, but that doesn't affect the numbering of later partitions.
>
> In the forensics situation you want to take a copy of a disk.
> But often that is impractical - copying this 500GB disk takes too long,
> or the scratch disk is not large enough, and the copy only holds the
> initial part of a disk.
> You do not want to discard such partial partitions - maybe clipping is OK,
> although I would prefer to see precisely the same data on the copy as on
> the original, except of course that actually accessing nonexistent data
> returns an I/O error, but discarding would again cause renumbering. Bad.
So your main points seem to be:
- removing access that people currently have is bad
- causing partitions to be renumbered is bad.
I certainly agree. Unless people actually do use partitions to bypass
the device-size check in generic_make_request, this patch doesn't do
either these bad things.
The only visible effect should be:
- partitions that have no accessible blocks will no longer be able to
be opened.
- partitions that start in-range and end beyond range will appear
smaller than they would have done.
- reading the last block of a partition will no longer cause error
messages that look like there are device errors.
All of these seem to be acceptable effects. Do you agree?
>
> [As an aside: for the past twelve years or so I have muttered once a year
> that it is bad that Linux does automatic probing for partitions.
> It will be mistaken every now and then.
> With some partition types there is a fairly large probability
> that random data is seen as a partition table.
> A correct system does not guess (unless asked to guess by the user).
> A correct system is set up in such a way that the boot parameters tell it
> 1. the root disk, 2. the partition type of the root disk,
> 3. the root partition, 4. the filesystem type of the root filesystem.
> Now the root disk can contain configuration data that causes the system
> to look at specified disks in specified ways, or to do default things.
>
> With a system that was set up correctly, your nonsense partitions
> would never have been found by the kernel, and I suppose mount by label
> would not have encountered any problems.]
I have substantial sympathy with your aside. But people don't want to
have to configure things. They just want it to "work". I get this
with md/raid all the time. "Just find all the arrays and assemble
them". Like with partitions, that isn't always a well defined
operation. But most of the time it is, and that is what people think
they want.
Ho hum.
Thanks for your input.
NeilBrown
-
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]
