Date: Sun, 12 Aug 2018 08:05:26 +0000 From: Emmanuel Dreyfus <m...@netbsd.org> Message-ID: <20180812080526.gf17...@homeworld.netbsd.org>
| 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