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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 15 2001 - 21:00:23 EST