Mike, On 6/14/18 21:38, Mike Snitzer wrote: > On Wed, Jun 13 2018 at 8:11pm -0400, > Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > >> Setting up a zoned disks in a generic form is not so trivial. There >> is also quite a bit of tribal knowledge with these devices which is not >> easy to find. >> >> The currently supplied demo script works but it is not generic enough to be >> practical for Linux distributions or even developers which often move >> from one kernel to another. >> >> This tries to put a bit of this tribal knowledge into an initial udev >> rule for development with the hopes Linux distributions can later >> deploy. Three rule are added. One rule is optional for now, it should be >> extended later to be more distribution-friendly and then I think this >> may be ready for consideration for integration on distributions. >> >> 1) scheduler setup > > This is wrong.. if zoned devices are so dependent on deadline or > mq-deadline then the kernel should allow them to be hardcoded. I know > Jens removed the API to do so but the fact that drivers need to rely on > hacks like this udev rule to get a functional device is proof we need to > allow drivers to impose the scheduler used. I agree. Switching scheduler in the kernel during device probe/bring-up would be my preferred choice. But until we come to a consensus on the best way to do this, I think that this udev rule is useful since the "scheduler=" kernel parameter is rather heavy handed and applies to all single queue devices. Not to mention that adding this parameter to the kernel arguments is in essence similar to the udev rule addition: action from the system user is necessary to achieve a correct configuration even though that could easily be done automatically from within the block layer. In the meantime, documenting properly that the deadline scheduler has a special relationship with zoned block devices is still a nice thing to do. But yes, dm-zoned-tools may not be the best place to do that. A simple text file under Documentation/block may be better. At the very least, Documentation/block/deadline-iosched.txt should have some mention of its almost mandatory use with zoned block devices. I will work on that. >> 2) backlist f2fs devices > > There should porbably be support in dm-zoned for detecting whether a > zoned device was formatted with f2fs (assuming there is a known f2fs > superblock)? That would certainly be nice to have and would not be too hard to code in dmzadm. I can add that and do what for instance mkfs.ext4 or mkfs.xfs do, which is ask for confirmation or bail out if an existing valid FS format is detected on the disk. That said, such test are far from common. mdadm for instance will happily format and start an array using unmounted disks with valid file systems on them. >> 3) run dmsetup for the rest of devices > > automagically running dmsetup directly from udev to create a dm-zoned > target is very much wrong. It just gets in the way of proper support > that should be add to appropriate tools that admins use to setup their > zoned devices. For instance, persistent use of dm-zoned target should > be made reliable with a volume manager.. > > In general this udev script is unwelcome and makes things way worse for > the long-term success of zoned devices. > > I don't dispute there is an obvious void for how to properly setup zoned > devices, but this script is _not_ what should fill that void. Fair points. I agree that it is hackish. The intent was as you say to temporarily fill a void. But granted, temporary hacks tend to stay (too) long around and can in the end get in the way of clean solutions. I will start looking into a proper fix for dm-zoned setup persistence. > So a heartfelt: > > Nacked-by: Mike Snitzer <snitzer@xxxxxxxxxx> Understood. I will revert and not document this udev rule in dm-zoned-tools. I was a little too quick in applying this patch and did not wait to see comments first. My bad. Thank you for your comments. Best regards. -- Damien Le Moal, Western Digital
