>>>>> "Neil" == Neil Brown <neilb@xxxxxxx> writes: Neil, Neil> Of these: Neil> max_hw_sectors_kb, nr_requests, rq_affinity, iosched/, Neil> max_sectors_kb scheduler nomerges rotational Neil> are really only relevant to the elevator code and those devices Neil> that used that code (ide, scsi, etc). I'm not sure I completely agree with putting rotational in that bucket. It affects the choice of allocation policy in btrfs, for instance. Neil> Of the others: Neil> hw_sector_size - is applicable to all block devices, and could Neil> reasonably be placed one level up in the Neil> device directory (along side 'size'). hw_sector_size is deprecated. It's now split into logical and physical_block_size. Neil> Adding a number of extra fields such as minimum_io_size, Neil> optimal_io_size etc to '/queue' seems to increase the number of Neil> aberrations and enforces md and dm device to have a /queue which Neil> is largely irrelevant. You seem to be hung up on the fact that you don't queue things. I think that's beside the point. You *do* have a request_queue thanks to calling blk_queue_make_request() in md.c. And there is more to request_queue than the values you brought up. Like the callback functions. I'm not saying that all the values in request_queue apply to MD, but I really don't understand what all the fuss is about. Other than the presence of the string "queue" in the choice of naming. Anyway. If you look at the request_queue in the current tree you'll see that the very limits we are discussing are contained in a separate struct. We can easily move that somewhere else at a later date if that is deemed the right thing to do. Neil> I have suggested to Martin that 2 are enough. I think I have covered this in a separate mail. You are mixing up hardware limitations and I/O hints on the grounds that they went in as part of the same patch set and live in the same place. fdisk/mdadm/dmsetup need to use physical_block_size and alignment_offset to prevent us from misaligning when setting up partitions and virtual block devices. Also, when stacking devices I need to know these values to ensure that the I/O hints set by MD/DM don't conflict with the underlying hardware limitations. There are also special cases like shared disk setups and filesystem journal padding that may need to know details of the hardware atomicity. mkfs.* can leverage minimum_io_size and optimal_io_size hints to choose block sizes and to lay out data structures on stripe boundaries. Just like we're doing today except using a common interface for all block devices instead of poking at MD and LVM internals. logical_block_size, physical_block_size and alignment_offset are hardware limits that need to be honored when creating a (virtual) block device or partition. The minimum/optimal write sizes are hints to the *user* of the block device about how to lay out things. If you look at my MD patch you'll see that I only set the I/O hints. The hardware settings are off limits for MD. I don't particularly care whether we store the values in queue/, topology/, metrics/, limits/ or in the device root. Nor whether we call it minimum_write_size instead of minimum_io_size. I'll be happy to roll up a renaming patch... -- Martin K. Petersen Oracle Linux Engineering -- 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
