> >> Partition access are bounds checked. The problem was that the
> >> partition bounds were incorrect. We could say that the kernel
> >> partition code should have done that sanity check, but there
> >> are even potentially times when overlapping partitions is the
> >> right thing.
[SNIPPED]
> Excuse me if all this is crazy, but I've always thought things
> were kind of weird.
>
> Maybe it is best to just have filesystems lock regions of the
> hard disk. The partition code itself would get read locks on
> all the partition table blocks. The swap code could get a write
> lock, filesystems would get either type as desired, etc.
[SNIPPED]
I think that most of the (total) fs destruction problems will go away
when/if the top-level disk driver(s) prevents access beyond the end of
the physical media.
In the case of a Adaptec SCSI controller that uses the the aic7xxx,
and three different brand SCSI disks, an attempted write somewhere
beyond the physical limits will make the disk-drives unusable until it
is low-level formatted. This is because subsequent READ CAPACITY command
will fail. This happens with way too much regularity here.
Device-specific information is put <somewhere> on the disk drive media.
Once it is wiped out, you have to start from scratch, i.e., low-level
format the drive.
Some IDE drives have a greater problem than this. Once their device-
specific information is gone, you can't do anything about it because
they don't all allow low-level formatting.
There should be a common point somewhere in the code, where a check
against the physical limits of a block-device will not waste too many
CPU cycles. The limits are obtained at boot-time anyway.
Cheers,
Dick Johnson
***** FILE SYSTEM MODIFIED *****
Penguin : Linux version 2.1.92 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu