On Wed, 2017-05-10 at 08:03 +1000, NeilBrown wrote: > On Tue, May 09 2017, Jeff Layton wrote: > > > An errseq_t is a way of recording errors in one place, and allowing any > > number of "subscribers" to tell whether an error has been set again > > since a previous time. > > > > It's implemented as an unsigned 32-bit value that is managed with atomic > > operations. The low order bits are designated to hold an error code > > (max size of MAX_ERRNO). The upper bits are used as a counter. > > > > The API works with consumers sampling an errseq_t value at a particular > > point in time. Later, that value can be used to tell whether new errors > > have been set since that time. > > > > Note that there is a 1 in 512k risk of collisions here if new errors > > are being recorded frequently, since we have so few bits to use as a > > counter. To mitigate this, one bit is used as a flag to tell whether the > > value has been sampled since a new value was recorded. That allows > > us to avoid bumping the counter if no one has sampled it since it > > was last bumped. > > > > Later patches will build on this infrastructure to change how writeback > > errors are tracked in the kernel. > > > > Signed-off-by: Jeff Layton <jlay...@redhat.com> > > I like that this is a separate lib/*.c - nicely structured too. > > Reviewed-by: NeilBrown <ne...@suse.com> > >
Thanks, yeah...it occurred to me that this scheme is not really specific to writeback errors. While I can't think of another use-case for errseq_t's right offhand, I think this makes for cleaner layering and should make it easy to use in other ways should they arise. -- Jeff Layton <jlay...@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
