On Tue, 31 Jan 2012 16:00:44 +0000 Niels de Vos <ndevos@xxxxxxxxxx> wrote: > On 01/26/2012 09:45 PM, Christoph Hellwig wrote: > > On Thu, Jan 26, 2012 at 01:40:51PM -0800, Andrew Morton wrote: > >> The Right Thing To Do here is to make the kernel behave logically and > >> predictably, then modify the userspace tools. But if we're modifying > >> the userspace tools then we would just change userspace to issue a > >> BLKFLSBUF to /dev/sda and leave the kernel alone. > > > > The right fix is to make partition and whole disk access coherent, > > which is fairly simply: > > > > - create the block device inode/mapping per gendisk, and only reference > > count it per block_device > > - make sure blkdev_get_block(s) applies the correct offset if used on > > partitions > > > > This surely looks like a better way to fix this issue. I am not sure yet > how much work that would involve and if I am the right person to fix > this. If nobody beats me to it, I might send a patch for review some > (undefined) time later. One concern I have with the proposal is that it would forever rule out support of >16T devices on 32-bit machines. At present with 64-bit sector_t and 32-bit pgoff_t, I think we'd have a reasonable chance of supporting, say, four 8T partitions on a 32T device. But if we were to switch the kernel from using four 4T address_spaces (sda1-4) over to using a single 32T address_space (sda) then we can rule it all out. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
