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
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:
33 matches
Mail list logo
