Re: block ioctl to read/write last sector

[Michael E Brown <michael_e_brown@dell.com>]

Hi Andries!

On Tue, 13 Feb 2001 Andries.Brouwer@cwi.nl wrote:

> >   The block device uses 1K blocksize, and will prevent userspace from
> > seeing the odd-block at the end of the disk, if the disk is odd-size.
> >
> >   IA-64 architecture defines a new partitioning scheme where there is a
> > backup of the partition table header in the last sector of the disk. While
> > we can read and write to this sector in the kernel partition code, we have
> > no way for userspace to update this partition block.
>
> Are you sure?

Yes.

The only alternative at this time is to use the scsi-generic tools to
read directly from the scsi-layer. But, of course, this only works with
scsi devices.

>
> There may be no easy, convenient way right now, but
> (without having checked anything) it seems to me
> that you can, also today.

Please go check :-)  I believe my statement stands: You cannot read or
write to odd-sectors at the end of the disk from userspace. (see below for
definition of odd sector...)

> Look at the addpart utility in the util-linux package.
> It will allow you to add a partition disjoint from
> previously existing partitions.
> And since a partition can start on an odd sector,
> this should allow you to also read the last sector.
>
> Do I overlook something?

Yes. The addpart utility just uses the block-layer ioctls to dynamically
add and/or remove partitions. What this is doing is just adjusting the
kernel's idea of what the current partition scheme is. This has _nothing_
to do with actually reading or writing data from the disk.

The ia64 gpt partitioning code defines a partition header at the front of
the disk and at the end of the disk. I definetly have a need to read and
write to these headers.

What this proposed patch does has _nothing_ to do with partitioning :-) It
is _only_ to read and write the last sector of the disk. It just so
happens that the reason that I have to read that last sector is to read a
partition header.

>
> Anyway, an ioctl just to read the last sector is too silly.
> An ioctl to change the blocksize is more reasonable.

That may be better, I don't know. That's why this is an RFC. Are there any
possible races with that method? It seems to me that you might adversely
affect io in progress by changing the blocksize. The method demonstrated
in this patch shouldn't do that.

> And I expect that this fixed blocksize will go soon.

That may be, I don't know that much about the block layer. All I know is
that, with the current structure, I cannot read or write to sectors where
(sector #) > total-disk-blocks - (total-disk-blocks /
(softblocksize/hardblocksize))

This ioctl can be deprecated when that is no longer the case.

>
> Andries
>

Thanks for the comments.

> [Sorry if precisely the same discussion has happened earlier -
> I have no memory.]
>

Not really. I have discussed this with some folks with Red Hat, but this
is the first discussion on L-K.
--
Michael Brown