> 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?
There may be no easy, convenient way right now, but
(without having checked anything) it seems to me
that you can, also today.
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?
Anyway, an ioctl just to read the last sector is too silly.
An ioctl to change the blocksize is more reasonable.
And I expect that this fixed blocksize will go soon.
Andries
[Sorry if precisely the same discussion has happened earlier -
I have no memory.]
Hi Andries!
On Tue, 13 Feb 2001 [email protected] 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
Michael E Brown wrote:
>
> >
> > 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.
>
block size changing is dangerous:
if you change the blocksize of a mounted partition you'll disrupt the
filesystem.
some kernels crash hard if you execute
swapon /dev/<insert your root device>
swapon won't overwrite your root fs: it changes the blocksize to 4kB and
then notices that there is no swap signature.
But the blocksize change is fatal.
> > And I expect that this fixed blocksize will go soon.
>
that's 2.5.
> 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))
>
I have one additional user space only idea:
have you tried raw-io? bind a raw device to the partition, IIRC raw-io
is always in 512 byte units.
Probably an ioctl is the better idea, but I'd use absolute sector
numbers (not relative to the end), and obviously 64-bit sector numbers -
2 TB isn't that far away.
--
Manfred
On Wed, 14 Feb 2001, Manfred Spraul wrote:
> I have one additional user space only idea:
> have you tried raw-io? bind a raw device to the partition, IIRC raw-io
> is always in 512 byte units.
That has been tried. No, it does not work. :-) Using Scsi-Generic is the
only way so far found, but of course, it only works on SCSI drives.
>
> Probably an ioctl is the better idea, but I'd use absolute sector
> numbers (not relative to the end), and obviously 64-bit sector numbers -
> 2 TB isn't that far away.
>
I was deliberately trying to limit the scope to avoid misuse. This is to
work around a flaw in the current API, not to create a new API. Limiting
access to only those blocks that would normally be inaccessible through
the normal API seemed like the best bet to me.
--
Michael Brown
Martin,
It looks like the numbers we picked for our respective IOCTLs conflict.
I think I can change mine to the next higher since your patch seems to
have been around longer. What is the general way to deal with these
conflicts?
--
Michael
On 13 Feb 2001, Martin K. Petersen wrote:
> >>>>> "Andries" == Andries Brouwer <[email protected]> writes:
>
> Andries> Anyway, an ioctl just to read the last sector is too silly.
> Andries> An ioctl to change the blocksize is more reasonable.
>
> I actually sent you a patch implementing this some time ago, remember?
> We need it for XFS...
>
> Patch against 2.4.2-pre3 follows.
>
>
>>>>> "Michael" == Michael E Brown <[email protected]> writes:
Michael,
Michael> It looks like the numbers we picked for our respective IOCTLs
Michael> conflict. I think I can change mine to the next higher since
Michael> your patch seems to have been around longer.
If you could pick another number that would be great. All the people
out there using XFS rely on the BLKSETSIZE ioctl, and mkfs.xfs would
break horribly with your patch.
Michael> What is the general way to deal with these conflicts?
Whoever applies the patch to the official tree deals with them :)
--
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
[email protected], http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/