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