Re: block ioctl to read/write last sector
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, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
> "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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 re-reading the code in question, I was too hasty in my assumptions. This might work, so I'll try it. I don't expect it to be awfully pretty, though :-( -- Michael Brown Linux System Group Dell Computer Corp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 per-partition basis. They are done on a whole block device basis. see
fs/block_dev.c in block_read() and block_write(). The following test kills
us:
if (blk_size[MAJOR(dev)])
size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
BLOCK_SIZE_BITS) >> blocksize_bits;
else
size = INT_MAX;
while (count>0) {
if (block >= size)
return written ? written : -ENOSPC;
--
Michael Brown
Linux Systems Group
Dell Computer Corp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
> 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 size. > The block layer uses 1024-byte soft blocksize. > This means that, at the _end_ of the disk there is a single sector > that represents half of a software sector. 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. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last 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 cannot access any other way. Example: Disk with 1001 blocks. Hardware 512-byte sector size. The block layer uses 1024-byte soft blocksize. This means that, at the _end_ of the disk there is a single sector that represents half of a software sector. The block layer will not normally let you read or write that sector because it is not a full sector. Another example: Disk with 7 blocks (very small disk :-). Hardware blocksize=512, Block layer uses 4096-byte blocksize. Now you have _three_ hardware blocks at the end of the disk that the block layer will not let you read or write. My patch allows an alternate method to access these sectors. My patch has nothing to do with partitioning. -- Michael Brown Linux Systems Group Dell Computer Corp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 scsi-emulation works only for ATAPI devices. CDROMs are normally ATAPI. HDs are normally just ATA. I don't think that would work, but I have not tried it, either. -- Michael Brown Linux Systems Group Dell Computer Corp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
> 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 through the kernel > to get to the low-level disk IO drivers. This was confirmed by my testing. Reading/writing via /dev/raw/rawX fails exactly the same way as for /dev/[sh]dX. > Accessing /dev/sg ought to work fine, but of course it > places much more load on the application programmer > and removes a ton of kernel safety-nets. I believe using ide-scsi would work, but you must pass "hdc=ide-scsi" at boot time, which isn't a big deal for accessing CD-ROMs, but to be used for arbitrary disks, makes life much more difficult. Now all your IDE disks need to think they're SCSI disks, at least for the boot in which you want to change the partition table. I wouldn't want to suggest to customers that they run this additional layer of abstraction all the time just in case they want to examine and/or change the partition table of just one disk at some time. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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. :-) 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 ? > > > > 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. -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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. :-) 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 ? 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. -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
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 through the kernel to get to the low-level disk IO drivers. This was confirmed by my testing. Reading/writing via /dev/raw/rawX fails exactly the same way as for /dev/[sh]dX. Accessing /dev/sg ought to work fine, but of course it places much more load on the application programmer and removes a ton of kernel safety-nets. I believe using ide-scsi would work, but you must pass "hdc=ide-scsi" at boot time, which isn't a big deal for accessing CD-ROMs, but to be used for arbitrary disks, makes life much more difficult. Now all your IDE disks need to think they're SCSI disks, at least for the boot in which you want to change the partition table. I wouldn't want to suggest to customers that they run this additional layer of abstraction all the time just in case they want to examine and/or change the partition table of just one disk at some time. Thanks, Matt -- Matt Domsch Dell Linux Systems Group Linux OS Development www.dell.com/linux - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 scsi-emulation works only for ATAPI devices. CDROMs are normally ATAPI. HDs are normally just ATA. I don't think that would work, but I have not tried it, either. -- Michael Brown Linux Systems Group Dell Computer Corp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last 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 cannot access any other way. Example: Disk with 1001 blocks. Hardware 512-byte sector size. The block layer uses 1024-byte soft blocksize. This means that, at the _end_ of the disk there is a single sector that represents half of a software sector. The block layer will not normally let you read or write that sector because it is not a full sector. Another example: Disk with 7 blocks (very small disk :-). Hardware blocksize=512, Block layer uses 4096-byte blocksize. Now you have _three_ hardware blocks at the end of the disk that the block layer will not let you read or write. My patch allows an alternate method to access these sectors. My patch has nothing to do with partitioning. -- Michael Brown Linux Systems Group Dell Computer Corp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 per-partition basis. They are done on a whole block device basis. see
fs/block_dev.c in block_read() and block_write(). The following test kills
us:
if (blk_size[MAJOR(dev)])
size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)]
BLOCK_SIZE_BITS) blocksize_bits;
else
size = INT_MAX;
while (count0) {
if (block = size)
return written ? written : -ENOSPC;
--
Michael Brown
Linux Systems Group
Dell Computer Corp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 re-reading the code in question, I was too hasty in my assumptions. This might work, so I'll try it. I don't expect it to be awfully pretty, though :-( -- Michael Brown Linux System Group Dell Computer Corp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
"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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: block ioctl to read/write last sector
> > 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 didn't seem
to work for me.
> I need to read/write the last 512-byte
> sector on an odd-sized disk (IDE and/or SCSI) from user space. Employing
> suggestions from you and l-k, I have implemented two IOCTLs that get/set
the
> blksize_size[MAJOR(dev)][MINOR(dev)] values (via set_blocksize()). In my
> application, I read the hardsector size of a disk device (/dev/sdb) via an
> IOCTL, read the current blksize_size, set it to the hardsector size, and
> then continue, resetting blksize_size back to the original value when
done.
>
> In between, I use fopen64() to open the device /dev/sdb (an odd-sized
disk),
> and lseek64()/fwrite64()/fread64() to write/read the last sector of the
disk
> as reported by the BLKGETSIZE ioctl. The seek succeeds, however, the
> reads/writes fail. Writes fail with "No space left on device". Read
> returns 0, indicating EOF. If I read/write the N-1th sector this way, it
> works just fine. On even-sized disks, this succeeds both with and
> without calling my new IOCTLs, as expected. On odd-sized disks, it
> fails in both cases.
Anton Altaparmakov responded:
> I am sure Andries will correct me if I am wrong but here is
> what I think of the situation at present:
>
> I suspect that you will find the problem in
> linux/fs/block_dev.c functions
> block_write() and block_read() which AFAIK only get called
> when you use
> usermode to read a /dev/* blockdevice as you probably are
> doing. From the
> kernel these functions AFAIK never get called and hence the problem
> doesn't exist (either way I am surprised that it works as looking at
> generic_make_request() there is a check of simillar type and AFAICS it
> would fail as well for the same reason. I probably don't understand
> something there and/or generic_make_request() is not being
> called either,
> as it obviously works, since you have tried it).
>
> In block_write() you find this (lines 58ff in the file in 2.4.0):
> [snip]
> if (blk_size[MAJOR(dev)])
> size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
> BLOCK_SIZE_BITS) >> blocksize_bits;
> else
> size = INT_MAX;
> while (count>0) {
> if (block >= size)
> return written ? written : -ENOSPC;
> [snip]
>
> As you can see when size is calculated blk_size is multiplied
> by 1024 and
> then divided by 512, effectively blk_size is multiplied by 2.
>
> The effect of this is that size has the lowest bit always
> equal to zero
> and hence it always will be even.
>
> The subsequent check "if (block >= size)" of course is then
> true and we
> return with -ENOSPC straight away.
>
> In block_read() you find this (lines 195ff in the file in 2.4.0):
> [snip]
> if (blk_size[MAJOR(dev)])
> size = (loff_t) blk_size[MAJOR(dev)][MINOR(dev)] <<
> BLOCK_SIZE_BITS;
> else
> size = (loff_t) INT_MAX << BLOCK_SIZE_BITS;
>
> if (offset > size)
> left = 0;
> [snip]
> if (left <= 0)
> return 0;
> [snip]
>
> And again size is equal to blk_size multiplied by 1024 and
> hence always
> will be even.
If this analysis is correct (and I think it is), changing the block size
doesn't actually solve the problem.
I've got no problems requiring any IOCTL (either block-size-changing or just
a read/write last sector) to check that a device isn't in use somehow prior
to making these calls. Changing a disk's partition table while partitions
are actively in use on it isn't generally a good idea. But, fdisk and other
partition table-changing apps don't do this kind of check now IIRC.
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
> "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.
--
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/
diff -urN linux/arch/mips64/kernel/ioctl32.c linux-blksetsize/arch/mips64/kernel/ioctl32.c
--- linux/arch/mips64/kernel/ioctl32.c Wed Nov 29 00:42:04 2000
+++ linux-blksetsize/arch/mips64/kernel/ioctl32.c Tue Feb 13 14:15:20 2001
@@ -712,6 +712,7 @@
IOCTL32_HANDLER(BLKPG, blkpg_ioctl_trans),
IOCTL32_DEFAULT(BLKELVGET),
IOCTL32_DEFAULT(BLKELVSET),
+ IOCTL32_DEFAULT(BLKSETSIZE),
IOCTL32_DEFAULT(MTIOCTOP), /* mtio.h ioctls */
IOCTL32_HANDLER(MTIOCGET32, mt_ioctl_trans),
diff -urN linux/arch/sparc64/kernel/ioctl32.c linux-blksetsize/arch/sparc64/kernel/ioctl32.c
--- linux/arch/sparc64/kernel/ioctl32.c Tue Feb 13 14:12:17 2001
+++ linux-blksetsize/arch/sparc64/kernel/ioctl32.c Tue Feb 13 14:15:20 2001
@@ -3107,6 +3107,7 @@
COMPATIBLE_IOCTL(BLKFRASET)
COMPATIBLE_IOCTL(BLKSECTSET)
COMPATIBLE_IOCTL(BLKSSZGET)
+COMPATIBLE_IOCTL(BLKSETSIZE)
/* RAID */
COMPATIBLE_IOCTL(RAID_VERSION)
diff -urN linux/drivers/block/blkpg.c linux-blksetsize/drivers/block/blkpg.c
--- linux/drivers/block/blkpg.c Fri Oct 27 02:35:47 2000
+++ linux-blksetsize/drivers/block/blkpg.c Tue Feb 13 14:15:20 2001
@@ -208,6 +208,7 @@
int blk_ioctl(kdev_t dev, unsigned int cmd, unsigned long arg)
{
int intval;
+ long longval;
switch (cmd) {
case BLKROSET:
@@ -258,6 +259,22 @@
longval = g->part[MINOR(dev)].nr_sects;
return put_user(longval, (long *) arg);
#endif
+ case BLKSETSIZE:
+ /* Can be used to set block size from userland. */
+ if(!capable(CAP_SYS_ADMIN))
+return -EACCES;
+
+ if(!dev || !arg)
+return -EINVAL;
+
+ if (get_user(longval, (int *)(arg)))
+return -EFAULT;
+
+ if (longval > PAGE_SIZE || longval < 512 || (longval & (longval-1)))
+return -EINVAL;
+
+ set_blocksize(dev, longval);
+ return 0;
#if 0
case BLKRRPART: /* Re-read partition tables */
if (!capable(CAP_SYS_ADMIN))
diff -urN linux/drivers/ide/ide.c linux-blksetsize/drivers/ide/ide.c
--- linux/drivers/ide/ide.c Tue Feb 13 14:12:23 2001
+++ linux-blksetsize/drivers/ide/ide.c Tue Feb 13 14:15:20 2001
@@ -2672,6 +2672,7 @@
case BLKPG:
case BLKELVGET:
case BLKELVSET:
+ case BLKSETSIZE:
return blk_ioctl(inode->i_rdev, cmd, arg);
default:
diff -urN linux/drivers/md/lvm.c linux-blksetsize/drivers/md/lvm.c
--- linux/drivers/md/lvm.c Sun Jan 28 19:11:20 2001
+++ linux-blksetsize/drivers/md/lvm.c Tue Feb 13 14:15:20 2001
@@ -910,6 +910,8 @@
return -EFAULT;
break;
+ case BLKSETSIZE:
+ return blk_ioctl(inode->i_rdev, command, a);
case BLKFLSBUF:
/* flush buffer cache */
diff -urN linux/drivers/md/md.c linux-blksetsize/drivers/md/md.c
--- linux/drivers/md/md.c Tue Feb 13 14:12:24 2001
+++ linux-blksetsize/drivers/md/md.c Tue Feb 13 14:15:20 2001
@@ -2511,6 +2511,9 @@
(long *) arg);
goto done;
+ case BLKSETSIZE:
+ return blk_ioctl(dev, cmd, (long *) arg);
+
case BLKFLSBUF:
fsync_dev(dev);
invalidate_buffers(dev);
diff -urN linux/drivers/scsi/sd.c linux-blksetsize/drivers/scsi/sd.c
--- linux/drivers/scsi/sd.c Tue Feb 13 14:12:32 2001
+++ linux-blksetsize/drivers/scsi/sd.c Tue Feb 13 14:15:21 2001
@@ -234,6 +234,7 @@
case BLKPG:
case BLKELVGET:
case BLKELVSET:
+case BLKSETSIZE:
return blk_ioctl(inode->i_rdev, cmd, arg);
case BLKRRPART: /* Re-read partition tables */
diff -urN linux/include/linux/fs.h linux-blksetsize/include/linux/fs.h
--- linux/include/linux/fs.h Tue Feb 13 14:12:42 2001
+++ linux-blksetsize/include/linux/fs.h Tue Feb 13 14:15:21 2001
@@ -181,6 +181,7 @@
#define BLKSECTSET _IO(0x12,102)/* set max sectors per request (ll_rw_blk.c) */
#define BLKSECTGET _IO(0x12,103)/* get max sectors per request (ll_rw_blk.c) */
#define BLKSSZGET _IO(0x12,104)/* get block device sector size */
+#define BLKSETSIZE _IO(0x12,108)/* set device block size */
#if 0
#define BLKPG _IO(0x12,105)/* See blkpg.h */
#define BLKELVGET _IOR(0x12,106,sizeof(blkelv_ioctl_arg_t))/* elevator get */
Re: block ioctl to read/write last sector
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/ 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 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. But it changes the idea of odd and even. A partition can start on an odd sector. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
> 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.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 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. But it changes the idea of odd and even. A partition can start on an odd sector. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
"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.
--
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/
diff -urN linux/arch/mips64/kernel/ioctl32.c linux-blksetsize/arch/mips64/kernel/ioctl32.c
--- linux/arch/mips64/kernel/ioctl32.c Wed Nov 29 00:42:04 2000
+++ linux-blksetsize/arch/mips64/kernel/ioctl32.c Tue Feb 13 14:15:20 2001
@@ -712,6 +712,7 @@
IOCTL32_HANDLER(BLKPG, blkpg_ioctl_trans),
IOCTL32_DEFAULT(BLKELVGET),
IOCTL32_DEFAULT(BLKELVSET),
+ IOCTL32_DEFAULT(BLKSETSIZE),
IOCTL32_DEFAULT(MTIOCTOP), /* mtio.h ioctls */
IOCTL32_HANDLER(MTIOCGET32, mt_ioctl_trans),
diff -urN linux/arch/sparc64/kernel/ioctl32.c linux-blksetsize/arch/sparc64/kernel/ioctl32.c
--- linux/arch/sparc64/kernel/ioctl32.c Tue Feb 13 14:12:17 2001
+++ linux-blksetsize/arch/sparc64/kernel/ioctl32.c Tue Feb 13 14:15:20 2001
@@ -3107,6 +3107,7 @@
COMPATIBLE_IOCTL(BLKFRASET)
COMPATIBLE_IOCTL(BLKSECTSET)
COMPATIBLE_IOCTL(BLKSSZGET)
+COMPATIBLE_IOCTL(BLKSETSIZE)
/* RAID */
COMPATIBLE_IOCTL(RAID_VERSION)
diff -urN linux/drivers/block/blkpg.c linux-blksetsize/drivers/block/blkpg.c
--- linux/drivers/block/blkpg.c Fri Oct 27 02:35:47 2000
+++ linux-blksetsize/drivers/block/blkpg.c Tue Feb 13 14:15:20 2001
@@ -208,6 +208,7 @@
int blk_ioctl(kdev_t dev, unsigned int cmd, unsigned long arg)
{
int intval;
+ long longval;
switch (cmd) {
case BLKROSET:
@@ -258,6 +259,22 @@
longval = g-part[MINOR(dev)].nr_sects;
return put_user(longval, (long *) arg);
#endif
+ case BLKSETSIZE:
+ /* Can be used to set block size from userland. */
+ if(!capable(CAP_SYS_ADMIN))
+return -EACCES;
+
+ if(!dev || !arg)
+return -EINVAL;
+
+ if (get_user(longval, (int *)(arg)))
+return -EFAULT;
+
+ if (longval PAGE_SIZE || longval 512 || (longval (longval-1)))
+return -EINVAL;
+
+ set_blocksize(dev, longval);
+ return 0;
#if 0
case BLKRRPART: /* Re-read partition tables */
if (!capable(CAP_SYS_ADMIN))
diff -urN linux/drivers/ide/ide.c linux-blksetsize/drivers/ide/ide.c
--- linux/drivers/ide/ide.c Tue Feb 13 14:12:23 2001
+++ linux-blksetsize/drivers/ide/ide.c Tue Feb 13 14:15:20 2001
@@ -2672,6 +2672,7 @@
case BLKPG:
case BLKELVGET:
case BLKELVSET:
+ case BLKSETSIZE:
return blk_ioctl(inode-i_rdev, cmd, arg);
default:
diff -urN linux/drivers/md/lvm.c linux-blksetsize/drivers/md/lvm.c
--- linux/drivers/md/lvm.c Sun Jan 28 19:11:20 2001
+++ linux-blksetsize/drivers/md/lvm.c Tue Feb 13 14:15:20 2001
@@ -910,6 +910,8 @@
return -EFAULT;
break;
+ case BLKSETSIZE:
+ return blk_ioctl(inode-i_rdev, command, a);
case BLKFLSBUF:
/* flush buffer cache */
diff -urN linux/drivers/md/md.c linux-blksetsize/drivers/md/md.c
--- linux/drivers/md/md.c Tue Feb 13 14:12:24 2001
+++ linux-blksetsize/drivers/md/md.c Tue Feb 13 14:15:20 2001
@@ -2511,6 +2511,9 @@
(long *) arg);
goto done;
+ case BLKSETSIZE:
+ return blk_ioctl(dev, cmd, (long *) arg);
+
case BLKFLSBUF:
fsync_dev(dev);
invalidate_buffers(dev);
diff -urN linux/drivers/scsi/sd.c linux-blksetsize/drivers/scsi/sd.c
--- linux/drivers/scsi/sd.c Tue Feb 13 14:12:32 2001
+++ linux-blksetsize/drivers/scsi/sd.c Tue Feb 13 14:15:21 2001
@@ -234,6 +234,7 @@
case BLKPG:
case BLKELVGET:
case BLKELVSET:
+case BLKSETSIZE:
return blk_ioctl(inode-i_rdev, cmd, arg);
case BLKRRPART: /* Re-read partition tables */
diff -urN linux/include/linux/fs.h linux-blksetsize/include/linux/fs.h
--- linux/include/linux/fs.h Tue Feb 13 14:12:42 2001
+++ linux-blksetsize/include/linux/fs.h Tue Feb 13 14:15:21 2001
@@ -181,6 +181,7 @@
#define BLKSECTSET _IO(0x12,102)/* set max sectors per request (ll_rw_blk.c) */
#define BLKSECTGET _IO(0x12,103)/* get max sectors per request (ll_rw_blk.c) */
#define BLKSSZGET _IO(0x12,104)/* get block device sector size */
+#define BLKSETSIZE _IO(0x12,108)/* set device block size */
#if 0
#define BLKPG _IO(0x12,105)/* See blkpg.h */
#define BLKELVGET _IOR(0x12,106,sizeof(blkelv_ioctl_arg_t))/* elevator get */
RE: block ioctl to read/write last sector
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 didn't seem
to work for me.
I need to read/write the last 512-byte
sector on an odd-sized disk (IDE and/or SCSI) from user space. Employing
suggestions from you and l-k, I have implemented two IOCTLs that get/set
the
blksize_size[MAJOR(dev)][MINOR(dev)] values (via set_blocksize()). In my
application, I read the hardsector size of a disk device (/dev/sdb) via an
IOCTL, read the current blksize_size, set it to the hardsector size, and
then continue, resetting blksize_size back to the original value when
done.
In between, I use fopen64() to open the device /dev/sdb (an odd-sized
disk),
and lseek64()/fwrite64()/fread64() to write/read the last sector of the
disk
as reported by the BLKGETSIZE ioctl. The seek succeeds, however, the
reads/writes fail. Writes fail with "No space left on device". Read
returns 0, indicating EOF. If I read/write the N-1th sector this way, it
works just fine. On even-sized disks, this succeeds both with and
without calling my new IOCTLs, as expected. On odd-sized disks, it
fails in both cases.
Anton Altaparmakov responded:
I am sure Andries will correct me if I am wrong but here is
what I think of the situation at present:
I suspect that you will find the problem in
linux/fs/block_dev.c functions
block_write() and block_read() which AFAIK only get called
when you use
usermode to read a /dev/* blockdevice as you probably are
doing. From the
kernel these functions AFAIK never get called and hence the problem
doesn't exist (either way I am surprised that it works as looking at
generic_make_request() there is a check of simillar type and AFAICS it
would fail as well for the same reason. I probably don't understand
something there and/or generic_make_request() is not being
called either,
as it obviously works, since you have tried it).
In block_write() you find this (lines 58ff in the file in 2.4.0):
[snip]
if (blk_size[MAJOR(dev)])
size = ((loff_t) blk_size[MAJOR(dev)][MINOR(dev)]
BLOCK_SIZE_BITS) blocksize_bits;
else
size = INT_MAX;
while (count0) {
if (block = size)
return written ? written : -ENOSPC;
[snip]
As you can see when size is calculated blk_size is multiplied
by 1024 and
then divided by 512, effectively blk_size is multiplied by 2.
The effect of this is that size has the lowest bit always
equal to zero
and hence it always will be even.
The subsequent check "if (block = size)" of course is then
true and we
return with -ENOSPC straight away.
In block_read() you find this (lines 195ff in the file in 2.4.0):
[snip]
if (blk_size[MAJOR(dev)])
size = (loff_t) blk_size[MAJOR(dev)][MINOR(dev)]
BLOCK_SIZE_BITS;
else
size = (loff_t) INT_MAX BLOCK_SIZE_BITS;
if (offset size)
left = 0;
[snip]
if (left = 0)
return 0;
[snip]
And again size is equal to blk_size multiplied by 1024 and
hence always
will be even.
If this analysis is correct (and I think it is), changing the block size
doesn't actually solve the problem.
I've got no problems requiring any IOCTL (either block-size-changing or just
a read/write last sector) to check that a device isn't in use somehow prior
to making these calls. Changing a disk's partition table while partitions
are actively in use on it isn't generally a good idea. But, fdisk and other
partition table-changing apps don't do this kind of check now IIRC.
Thanks,
Matt
--
Matt Domsch
Dell Linux Systems Group
Linux OS Development
www.dell.com/linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block ioctl to read/write last sector
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
