[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort xenstore-ls if a node disappears while iterating



On 20.03.20 15:58, David Woodhouse wrote:
On Fri, 2020-03-20 at 14:12 +0000, Ian Jackson wrote:
Jürgen Groß writes ("Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort 
xenstore-ls if a node disappears while iterating"):
No, you just don't care for the transaction to succeed or fail (IMO it
should never fail as you are reading only).

So just wrap everything into a transaction.

Yes.  xenstored will do the needed buffering.

I think in principle there is a risk here that the transaction might
run for a long time, if the output from xenstore-ls goes to something
that blocks (eg a pager) and can't be written all at once.

But if this is a problem it is a problem afflicting xenstored, not
xenstore-ls.

Ian.


So if I do this...

--- a/tools/xenstore/xenstore_client.c
+++ b/tools/xenstore/xenstore_client.c
@@ -658,7 +658,6 @@ main(int argc, char **argv)
      case MODE_write:
         transaction = (argc - switch_argv - optind) > 2;
         break;
-    case MODE_ls:
      case MODE_watch:
         transaction = 0;
         break;
@@ -683,6 +682,7 @@ again:
         xth = xs_transaction_start(xsh);
         if (xth == XBT_NULL)
             errx(1, "couldn't start transaction");
+        printf("started transaction\n");
      }
ret = perform(mode, optind, argc - switch_argv, argv + switch_argv, xsh, xth, prefix, tidy, upto, recurse, nr_watches, raw);


... and then repeat my test case as shown in [PATCH 1/1], I should no
longer see...

xenstore-ls:
could not access permissions for 407: No such file or directory
xenstore-ls: in xs_directory (/local/domain/2/foo/407): No such file or 
directory
0


But it does still happen. And even if I turn the errx() into a warn()
to stop it aborting, and add a warn() when the xs_transaction_end()
returns EAGAIN... that isn't happening either. I'm just getting
inconsistent data, within a transaction.

Hmm, yes, thinking more about it: a non-transactional write of a node
which hasn't been written or read by an ongoing transaction is not
handled in a special way. This could be changed, but would require some
structural changes.


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.