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