[dm-devel] [PATCH v4 09/20] libmultipath: functions to indicate mapping failure in /dev/shm

[Martin Wilck]

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 at suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)