On Wed, 14 Feb 2001, David Balazic wrote:
> Did you try scsi-emulation on IDE disks ?
Don't be silly.
That emulation is from scsi-packet to atapi-packet.
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
On Wed, 14 Feb 2001, David Balazic wrote:
Did you try scsi-emulation on IDE disks ?
Don't be silly.
That emulation is from scsi-packet to atapi-packet.
Andre Hedrick
Linux ATA Development
ASL Kernel Development
-
ASL,
> "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
On Wed, 14 Feb 2001 [EMAIL PROTECTED] wrote:
>
> Maybe. I think that you'll find that these blocks are
> relative to the start of the partition, not relative
> to the start of the disk.
>
> So if you add a 1-block partition that contains the last
> sector of the disk, all should be fine.
>
Ok.
On Wed, 14 Feb 2001 [EMAIL PROTECTED] wrote:
>
> So if you add a 1-block partition that contains the last
> sector of the disk, all should be fine.
>
Oh! I didn't get your meaning before. I think I understand now. The
problem with this is that the tests for block writeability are not done on
a
> My patch has nothing to do with partitioning.
Yes, you already said that, and I understand you very well.
My suggestion, and I have not checked the code to make sure,
but off-hand it seems to me that it should work,
is to use a partition.
> Disk with 1001 blocks. Hardware 512-byte sector
On Wed, 14 Feb 2001 [EMAIL PROTECTED] wrote:
> But it changes the idea of odd and even.
> A partition can start on an odd sector.
>
That is orthogonal to the issue that I am trying to solve with my patch.
My code is trying to make it possible to access sectors at the _end_ of
the disk that you
On Wed, 14 Feb 2001, David Balazic wrote:
> Michael E Brown ([EMAIL PROTECTED]) worte :
>
> > 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.
>
> Did you try scsi-emulation on IDE disks ?
I think
> 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.
Steven Tweedie responded to my question about that:
> Raw IO is subject to the same limits as other IO, because
> ultimately it uses the same
Michael E Brown ([EMAIL PROTECTED]) worte :
> 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
Michael E Brown ([EMAIL PROTECTED]) worte :
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. :-)
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.
Steven Tweedie responded to my question about that:
Raw IO is subject to the same limits as other IO, because
ultimately it uses the same route
On Wed, 14 Feb 2001, David Balazic wrote:
Michael E Brown ([EMAIL PROTECTED]) worte :
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.
Did you try scsi-emulation on IDE disks ?
I think that
On Wed, 14 Feb 2001 [EMAIL PROTECTED] wrote:
But it changes the idea of odd and even.
A partition can start on an odd sector.
That is orthogonal to the issue that I am trying to solve with my patch.
My code is trying to make it possible to access sectors at the _end_ of
the disk that you
On Wed, 14 Feb 2001 [EMAIL PROTECTED] wrote:
So if you add a 1-block partition that contains the last
sector of the disk, all should be fine.
Oh! I didn't get your meaning before. I think I understand now. The
problem with this is that the tests for block writeability are not done on
a
On Wed, 14 Feb 2001 [EMAIL PROTECTED] wrote:
Maybe. I think that you'll find that these blocks are
relative to the start of the partition, not relative
to the start of the disk.
So if you add a 1-block partition that contains the last
sector of the disk, all should be fine.
Ok. Upon
"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
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:
> >
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
> > 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?
I'm not sure, but when I asked about this in January, I suggested having an
IOCTL that get/set
> "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
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
From [EMAIL PROTECTED] Wed Feb 14 00:37:25 2001
> 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
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
> 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
To address the concerns of Andi Kleen, with a good suggestion from Richard
Johnson, I have revised my previous patch attempt. Please check this out
and comment.
Changelog:
1) use get_gendisk() instead of walking array manually
2) pass in struct instead of guessing..
+ struct {
+
To address the concerns of Andi Kleen, with a good suggestion from Richard
Johnson, I have revised my previous patch attempt. Please check this out
and comment.
Changelog:
1) use get_gendisk() instead of walking array manually
2) pass in struct instead of guessing..
+ struct {
+
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
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
From [EMAIL PROTECTED] Wed Feb 14 00:37:25 2001
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
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
"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
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?
I'm not sure, but when I asked about this in January, I suggested having an
IOCTL that get/set blksize_size[MAJOR(dev)][MINOR(dev)], which
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
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:
On 7 Feb 2001, Andi Kleen wrote:
> But what happens when you e.g. run a software blocksize of 4096 and the device
> has >1 inaccessible 512 byte sector at the end?
> I think it would be better to pass in a offset in 512 byte units to a special
> ioctl (and do error checking in the driver for
Michael E Brown <[EMAIL PROTECTED]> writes:
> Problem Summary:
> There is no function exported to userspace to read or write the last
> 512-byte sector of an odd-size disk.
>
> The block device uses 1K blocksize, and will prevent userspace from
> seeing the odd-block at the end of the disk,
Michael E Brown [EMAIL PROTECTED] writes:
Problem Summary:
There is no function exported to userspace to read or write the last
512-byte sector of an odd-size disk.
The block device uses 1K blocksize, and will prevent userspace from
seeing the odd-block at the end of the disk, if the
On 7 Feb 2001, Andi Kleen wrote:
But what happens when you e.g. run a software blocksize of 4096 and the device
has 1 inaccessible 512 byte sector at the end?
I think it would be better to pass in a offset in 512 byte units to a special
ioctl (and do error checking in the driver for
Problem Summary:
There is no function exported to userspace to read or write the last
512-byte sector of an odd-size disk.
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
Problem Summary:
There is no function exported to userspace to read or write the last
512-byte sector of an odd-size disk.
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
41 matches
Mail list logo