Messages in this thread | | | Date | Wed, 14 Feb 2001 01:21:39 +0100 | From | Manfred Spraul <> | Subject | Re: block ioctl to read/write last sector |
| |
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/
| |