Re: block ioctl to read/write last sector

Re: block ioctl to read/write last sector

[Andries.Brouwer]

    From michael_e_brown@dell.com 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

Re: block ioctl to read/write last sector

[Michael E Brown]

On Wed, 14 Feb 2001 Andries.Brouwer@cwi.nl 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

Re: block ioctl to read/write last sector

[Andries.Brouwer]

> 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

Re: block ioctl to read/write last sector

[Michael E Brown]

On Wed, 14 Feb 2001 Andries.Brouwer@cwi.nl 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

Re: block ioctl to read/write last sector

[Michael E Brown]

On Wed, 14 Feb 2001 Andries.Brouwer@cwi.nl 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

RE: block ioctl to read/write last sector

[Matt_Domsch]

> 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

Re: block ioctl to read/write last sector

[David Balazic]

Michael E Brown (michael_e_brown@dell.com) 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
- - - - - - - - - - - - - - - - - - - - - -

Re: block ioctl to read/write last sector

[Michael E Brown]

On Wed, 14 Feb 2001, David Balazic wrote:

> Michael E Brown (michael_e_brown@dell.com) 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

Re: block ioctl to read/write last sector

[Andre Hedrick]

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 95035                            Web: www.aslab.com

RE: block ioctl to read/write last sector

[Matt_Domsch]

> > 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

Re: block ioctl to read/write last sector

[Andries.Brouwer]

>   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.]

Re: block ioctl to read/write last sector

[Martin K. Petersen]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

>>>>> "Andries" == Andries Brouwer <Andries.Brouwer@cwi.nl> 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.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: blksetsize-2.4.2pre3.patch --]
[-- Type: text/x-patch, Size: 3978 bytes --]

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]

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 <Andries.Brouwer@cwi.nl> 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.
>
>

Re: block ioctl to read/write last sector

[Martin K. Petersen]

>>>>> "Michael" == Michael E Brown <michael_e_brown@dell.com> 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.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

Re: block ioctl to read/write last sector

[Michael E Brown]

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

Re: block ioctl to read/write last sector

[Manfred Spraul]

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

Re: block ioctl to read/write last sector

[Michael E Brown]

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