I'm implementing code to handle the Intel EFI GUID Partition Table 
specification, available at http://developer.intel.com/technology/efi.  
Per the spec, a primary GUID partition table is stored on the disk at 
physical sector 1, and a backup of that partition table is stored on the 
last sector of the disk.  On an even-sized disk, user-space tools can 
read/write the last sector.  On an odd-sized disk, they cannot.

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

From kernel space, I can bread() the last block with no problems after 
changing the blksize_size, only from user-space do I still have problems.

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.  Is 
there anything else I must do to make my change take affect that you can 
suggest?

I open this against all platforms, as I need it to function on IA-64 first 
in the Florence release, but the problem is generic.

I posed this question to Andries Brouwer and Anton Altaparmakov.  Anton 
responded:

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.

My solution is to have my own kernel patch which changes the constant
BLOCK_SIZE_BITE to 512 so that everything works fine. This also has the
effect that blk_size[] is in units of 512 rather than 1024. - Changing the
constant also results in quite a few other changes in the kernel as
unfortunately it is very often the case that people have assumed that
BLOCK_SIZE_BITS == 1024 and have hard coded either the 1024 as a number or
done something else equally shortsighted resulting in the kernel
blockdevice/vfs side breaking completely when you change the
BLOCK_SIZE_BITS. [Note that my patch only modifies the parts of the kernel
I compile in and by no means fixes all block devices / filesystems. - It
definitely makes both ide and scsi work for me but AFAICS it brakes
software RAID at the very least and potentially a lot of filesystems (my
patch fixes up only ext2 as I don't use anything else except for NTFS
which works fine). - If you are interested in my patch just let me know
and I can email it to you (note that it is for kernel version 2.4.0-test8
so I don't know if it still will apply cleanly to 2.4.0 proper but it
should be easy to fix).

Plese let me know how you get on as I have a strong interest in getting
this to work myself for the NTFStools I am writing!

Best regards,

	Anton