Re: Finding an available fss device

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 12 Aug 2018 08:05:26 +0000
    From:        Emmanuel Dreyfus <manu%netbsd.org@localhost>
    Message-ID:  <20180812080526.GF17137%homeworld.netbsd.org@localhost>

  |  Why would test then lock?

Because it avoids the overheads of acquiring a lock for no
particularly good purpose, only to immediately release it
again?   It would be different if it were to make a difference
to anything, obviously.

Clearly there's no point locking before testing for FWRITE
in flag, that's a local var (param) to this function, but the
"if it is locked it must be active" is not correct I think, there
might just be some other process doing a FSSIOCGET
or something at the same time as the attempt to FSSIOCSET.
The GET needs to lock, to return consistent values, but that does
not mean that this fss has an active snapshot.

The change you propose has subtly altered the semantics
another way as well (which probably does not matter) in that
previously if a FSSIOCSET just as the previous fss use was
being closed down, previously the ioctl would have waited on
the lock, and then succeeded, now it will fail (so would my change).

Lastly, it is clear (well, I think) that you and hannken@ are
talking at cross purposes, though whether this alters his answer
I have no idea (nor do I know the answer), but when you said:

	snapshot /mount0 on fss0 and /mount1 on fss1?

I am fairly sure that you meant "snapshot the filesystem which is
mounted on /mount0 (using fss0) and also snapshot the filesystem
which is mounted on /mount1 (using fss1)" where I believe your
words might have been interpreted as "make a snapshot of some
filesystem using fss0, and make that available as /mount0, and
make another snapshot of the same filesystem (using fss1) and
expose that as /mount1.

It is best to be very clear about exactly what you mean, not use
shorthand.

kre