On Thu, 2018-04-12 at 13:33 -0500, Benjamin Marzinski wrote: > On Wed, Apr 04, 2018 at 06:16:16PM +0200, Martin Wilck wrote: > > Create a simple API that indicates failure to create a map for a > > certain WWID. This will allow multipathd to indicate to other tools > > (in particular, "multipath -u" during udev processing) that > > an attempt to create a map for a certain wwid failed. > > > > The indicator is simply the existence of a file under > > /dev/shm/multipath/failed_wwids. > > I'm a little confused about the necessity of a lock file here. What > it > the race that you are worried about? If two processes try to create a > file at the same time, surely one of them will succeed. If two > processes > try to delete a file at the same time, it will get deleted. If one > process is trying to create a file and one is trying to remove it, > the > outcome depends on the who wins the race. But this is true whether > you > add a lock file to make those actions atomic or not. The same goes > with > stating a file that's being created or removed. As far a I can tell, > this should work if you simply create an empty file without any > locking. > Are you worried about some odd errno due to a race? My thinking was that it's generally a good thing to make file system operations like this atomic, and the well-tested and mature open_file() API was there ready to be used, thus I did. You're probably right that the locking not strictly necessary. I don't think it hurts, performance-wise the impact is quite low. Do you require me to change this, or can we change it later? Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
