Messages in this thread | | | Date | Sat, 29 Aug 2015 15:52:25 +0200 | From | Christoph Hellwig <> | Subject | Re: Persistent Reservation API V3 |
| |
On Fri, Aug 28, 2015 at 08:33:24PM -0500, Jeremy Linton wrote: > Hello, > So, looking at this, I don't see how it supports the algorithm I've been using > for years. For that algorithm to successfully migrate PRs across multiple paths > on a single machine without affecting other possible users (who may legitimately > have PR'ed the same device) I need PR_IN SA 1, READ RESERVATIONS to assure the > current node owns the reservation before attempting to preempt it on another > path. This can also assure that the device hasn't been reserved with a legacy > reservation.
Do you have any code describing this in more detail? We could add the read side as well if there is strong interest.
> So, this leads me to two more general questions. The first is why isn't the PR > API simply exported to filesystems as a general reserve/release so that the PR > happens during mount/dismount. Then DM and friends can be setup to transparently > migrate or share the reservation, rather than depending on userspace to handle > these operations...
The API can be used by file systems, and my upcoming NFS SCSI layout support was the main reason to write this.
> Also, it seems to me the use of CLEAR is extremely dangerous in any environment > where actual arbitration or sharing of the resource is taking place.
Yes, but having it as a specific API isn't any less dangerous than having it issued using SG_IO. Reservations really only make sense if you assume every user of a LU is actually cooperating in some way and not actively hostile.
| |