A possible solution for bug 624985, which I also just filled for device-mapper-multipath is to add our custom aliases to the bindings file. However, a collegue immediately complained that he observed the binding file got overwritten in the past. So checked the code and open_bindings_file() opens the file with
fd = open(file, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
I suggest to add O_APPEND here.
Can you recreate this? multipath does a seek immediately before it writes to the bindings file. It also locks the bindings file with a fcntl lock, so that no other multipath thread can write to the bindings file while it is doing this. Admittedly, this doesn't prevent a user who is hand editting the file from messing with it, but there is a warning against that at the top of the bindings file, and there is no way to prevent the much more likely problem here, where the user simply saves over a bindings file that got modified after they started editting it.
I'm not strongly against having O_APPEND here, since multipath always wants to be writing to the end of the file, but without a reproducer, it doesn't appear that this will actually fix a bug. I'm not saying that there isn't a bug that can cause the bindings file to get corrupted, but it doesn't appear that O_APPEND will change this. Unless you can actually see this issue, I suggest that this bug be moved to fedora.
No sorry, I cannot reproduce. As I said, I internally suggested to workaround bug 624985 by using the bindings file and then a colleagure intervented and so I went ahead and quickly checked the code...
We probably also need to check when exactly multipathd opens the file. If the file is open all the time, it might easily race. I have not check yet what it will do before it writes.
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release. Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products. This request is not yet committed for inclusion in