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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
