Date: Thu, 26 Nov 2015 19:33:00 +0000 From: David Holland <dholland-t...@netbsd.org> Message-ID: <20151126193300.ga28...@netbsd.org>
| Ewww.... It is easy to see why this happens in the CGD source, I think there's even an XXX comment that is related ... an easy "fix" would just be to multiply the size by 8 (by the appropriate factor really, of course) but that then makes the CGD look like it is a 512 bye/sec device, which would permit 512 byte reads on odd boundaries, which the underlying drive cannot handle. That could be fixed the same way that drives with 4K sectors and 512 byte addressing do it, using rd/mod/wrt sequences, doing 4K I/O to the drive and carving out 512 byte pieces, but I really don't believe that's the right solution. Making the CGD believe its underlying sectors are 4K panics the system. (That's about as far as I got, but I think the problem is related to translation between units, being done when it shouldn't be.) | I was already under the impression that ccd was a candidate for | extermination even before this came up. One possibility might be to keep it, but restrict it to only work when the underlying drives have 512 byte sectors - simply refuse to operate on 4k (or other) drives. That would keep compat for anyone currently using it (I can more or less guarantee no-one is successfully using it on 4K disks) and avoid needing to find a fix for it that would be rational. number, everywhere [...] | The problem I see with carrying around unit values at runtime (besides | potential overhead) is that at least in FS-level code I doubt that the FS level code can change much, or needs to. One thing I have assumed all along is that the file system structs cannot be altered (in kernel stuff could have some tweaks if needed, but the on-disk structs need to be unchanged, to keep compat with existing filesystems). At most, a translation from file system units (DEV_BSIZE almost for sure, at least in FFS) to whatever is decided for the lower level parts of the kernel, done only at the interface between the two, is what is needed. So, all block numbers in a FFS (even on a 4k sector disk) would still be in DEV_BSIZE units, they'd just always be conveniently multiples of 8... kre