On Mon, Dec 10, 2018 at 9:31 AM Evan Green <evgreen@xxxxxxxxxxxx> wrote: > > On Wed, Dec 5, 2018 at 7:15 PM Martin K. Petersen > <martin.petersen@xxxxxxxxxx> wrote: > > > > > > Evan, > > > > > Ah, I see. But I think it's useful to reflect max_discard_sectors, > > > max_write_zeroes_sectors, discard_granularity, and discard_alignment > > > from the block device to the loop device. With the exception of > > > discard_alignment, these parameters are visible via sysfs, > > > > discard_alignment is visible in sysfs, just not in the queue directory > > since alignment can be different on a per-partition basis. So there is > > one discard_alignment at the root of each /sys/block/foo directory and > > one for each partition subdirectory. This mirrors the alignment_offset > > variable which indicates a partitions alignment wrt. the underlying > > physical block size. > > > > That said, there are not many devices that actually report a non-zero > > discard alignment so it's not as useful as the device manufacturers > > (that were looking for an implementation shortcut) envisioned. > > Ah ok, thanks. > > > > > > I'm not totally sure about discard_alignment, that seems to be useful > > > in cases of merging blk requests. So I can stop mirroring that one if > > > it's harmful or not helpful. But unless it's a nak, I'd really love to > > > keep most of the mirroring. In which case the bool doesn't do a whole > > > lot of simplifying. > > > > I think it's fine to export these. The block device topology was > > explicitly designed to be stackable like this. > > Yeah, it seemed to fall in pretty naturally, which is why I was hoping > it might not be so controversial. Thanks Martin. Any other thoughts about this series? Ming, I did go back and experiment a little. The pseudocode you had proposed earlier would work, and solve the error prints I was seeing. But I still would like to keep the reflection of the block device properties, since that allows discard to be used on block devices that do support it. -Evan
