> Regarding lzc_list_*, I need to think about that. The channel program > iteration is great if everything is done within a program. But what if > userland needs the list? Then the atomicity argument is immediately not > applicable.
The semantics of channel program iteration are a little better than the current interface because it gives you a point-in-time snapshot of the state. i.e. the state was exactly this at some point while the channel program was running. Vs. with getting one dataset/snapshot at a time, the only guarantee is that things that exist across the whole iteration are returned exactly once. For example, if you create two snapshots A and B, in that order, while the iteration is in progress, then the channel program can show you [] (neither A or B), [A], or [A B]. But the one-at-a-time iteration can also show you [B]. I.e. B is listed but A is not, even though A was created before B. That said, this is a minor point. ZPL directory listing has the same semantic as the one-at-a-time iteration. > Also, if the list of children is huge, can there be any problems with > returning it userland? Yeah, it could take a long time while holding the config lock, or it could fail if userland didn't allocate enough memory to return it. I'll admit that the argument for ZCP listing as a replacement for the current one-at-a-time iteration is not super strong - they both have some pro's and con's. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/508#issuecomment-376975504 ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/T3507ad6a4df1e9bb-M86ca25a4e08ef0fff7497b4e Delivery options: https://openzfs.topicbox.com/groups
