Project

General

Profile

Bug #5701

zpool list reports incorrect "alloc" value for cache devices

Added by Prakash Surya over 4 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2015-03-10
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Running on a production system, the `zpool list -v` commands lists incorrect value for "ALLOC" and "FREE", see here:

NAME           SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
...
cache             -      -      -         -      -      -
  c4t5d0       460G  4.21T  16.0E        8M     0%   938%
  c4t6d0       460G  4.22T  16.0E        8M     0%   938%
...

The device is only 460G in size:

$ sudo -u delphix sudo prtvtoc /dev/rdsk/c4t5d0
* /dev/rdsk/c4t5d0 partition map
*
* Dimensions:
*     512 bytes/sector
* 964689920 sectors
* 964689853 accessible sectors
*
...

The l2arc vdev space accounting was broken as of the landing of the
l2arc RAM reduction patch (89c86e3), as that patch completely removed a
couple calls to vdev_space_update(). The issue was compounded with the
lock change in l2arc_write_buffers() that went in with the arc_state
contention patch (244781f), as buffers could now be release with its
ARC_FLAG_L2_WRITING flag set without having been issued to the l2arc
device (this results in decrements without accompanying increments).

I'll propose a fix soon.

History

#1

Updated by Prakash Surya over 4 years ago

Please see this review: https://reviews.csiden.org/r/175/

#2

Updated by Electric Monk over 4 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit a52fc310ba80fa3b2006110936198de7f828cd94

commit  a52fc310ba80fa3b2006110936198de7f828cd94
Author: Prakash Surya <prakash.surya@delphix.com>
Date:   2015-04-15T15:00:32.000Z

    5701 zpool list reports incorrect "alloc" value for cache devices
    Reviewed by: Matthew Ahrens <mahrens@delphix.com>
    Reviewed by: George Wilson <george@delphix.com>
    Reviewed by: Alek Pinchuk <alek.pinchuk@nexenta.com>
    Approved by: Dan McDonald <danmcd@omniti.com>

#3

Updated by Ben RUBSON about 3 years ago

Sounds like this bug is back, see #7410.

Also available in: Atom PDF