On Wed, Apr 17, 2024 at 12:59:51PM +0100, Jonathan Cameron wrote: > On Tue, 16 Apr 2024 09:37:09 -0700 > fan <nifan....@gmail.com> wrote: > > > > > Currently, we do not allow releasing an extent when it is still pending, > > which aligns with the case you mentioned above "not release for reuse", I > > think. > > Can the second add mean a retry instead of reuse? > No - or at least the device should not be doing that. The FM might try > again, but only once it knows try 1 failed. For reasons of this aligning > with MHD case where you definitely can't offer it to more than one host, > I think we should not do it. Whether we should put any effort into blocking > it is a different question. User error :) > > Note, the host must not remove a log entry until it has dealt with it > (sent a response) so there is no obvious reason to bother with a retry. > Maybe a booting host would reject all offered extents (because it's not ready > for them yet), but then I'd want the FM to explicitly decide to tell the > device > to offer gain. >
This might be the only time a forced-removal makes sense, considering that removal of a pending add could be potentially catestrophic, but if the FM knows the host is not coming up and never coming up, an allocation stuck in pending would not be recoverable unless you force-removed it. > Whilst this is a custom interface, the equivalent FM API does say. > > "The command, with selection policy Enable Shared Access, shall also fail > with Invalid > Input under the following conditions: > • When the specified region is not Sharable > • When the tagged capacity is already mapped to any Host ID via a non-Sharable > region > • When the tagged capacity cannot be added to the requested region due to > deviceimposed > restrictions > • When the same tagged capacity is currently accessible by the same LD" > > Little fuzzy because of the whole pending vs 'mapped / accessible' wording but > I think intent is you can't send again until first one is dealt with. > > Jonathan > > > > > Fan > > > > > > > > > > > > From the kernel side, if the first one is accepted, the second one will > > > > get rejected, and there is no issue there. > > > > If the first is reject for some reason, the second one can get > > > > accepted or rejected and do not need to worry about the first one. > > > > > > > > > > > > Fan > > > > > > > >
