On Wed, Apr 22, 2015 at 12:18 PM, David Pacheco <[email protected]> wrote:
> We have a number of storage pools that report "16.0E" for the "freeing" > property. Using "-p" to get a more precise number, we have values like > these: > > 18446744072282297939 > 18446744073709544128 > 18446744073709549120 > > or, as signed 64-bit values: > > -1427253677 > -7488 > -2496 > > Have others seen this? > I haven't. > Given that this seems to indicate that we've freed more data than we > expected to, could this be indicative of corruption? > I'd say these values being wrong is "corruption" by itself (albeit mostly harmless), but it could also be indicative of a larger problem. > In case it's relevant: most of the affected systems were previously > affected by spacemap corruption related to async destroy[1]. > That could definitely cause this -- if we free the same block twice, you'd get the spacemap corruption, and also the "freeing" would be decremented twice for the same block, causing it to eventually go negative. > But the system with the largest negative value was installed recently and > has only ever run bits as new as February.[2] > I don't know what would cause that. The first step to tracking this down would probably be to determine whether it's due to background free of filesystems/zvols vs snapshots. --matt > > Thanks, > Dave > > [1] https://www.illumos.org/issues/4504 > [2] To be precise: > https://github.com/joyent/illumos-joyent/tree/e1f322da435434b3a1f9c091e431efae6816ae4c > . > > > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
