1. 30 3月, 2018 4 次提交
    • H
      lightnvm: pblk: allow allocation of new lines during shutdown · b966c50b
      Hans Holmberg 提交于
      When shutting down pblk the write buffer is flushed and if the
      current line can't fit the data in the write buffer we need
      to allocate a new line, so remove the check that prevents this.
      Signed-off-by: NHans Holmberg <hans.holmberg@cnexlabs.com>
      Reviewed-by: NJavier González <javier@cnexlabs.com>
      Signed-off-by: NMatias Bjørling <mb@lightnvm.io>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      b966c50b
    • H
      lightnvm: pblk: export write amplification counters to sysfs · 76758390
      Hans Holmberg 提交于
      In a SSD, write amplification, WA, is defined as the average
      number of page writes per user page write. Write amplification
      negatively affects write performance and decreases the lifetime
      of the disk, so it's a useful metric to add to sysfs.
      
      In plkb's case, the number of writes per user sector is the sum of:
      
          (1) number of user writes
          (2) number of sectors written by the garbage collector
          (3) number of sectors padded (i.e. due to syncs)
      
      This patch adds persistent counters for 1-3 and two sysfs attributes
      to export these along with WA calculated with five decimals:
      
          write_amp_mileage: the accumulated write amplification stats
                            for the lifetime of the pblk instance
      
          write_amp_trip: resetable stats to facilitate delta measurements,
                          values reset at creation and if 0 is written
                          to the attribute.
      
      64-bit counters are used as a 32 bit counter would wrap around
      already after about 17 TB worth of user data. It will take a
      long long time before the 64 bit sector counters wrap around.
      
      The counters are stored after the bad block bitmap in the first
      emeta sector of each written line. There is plenty of space in the
      first emeta sector, so we don't need to bump the major version of
      the line data format.
      Signed-off-by: NHans Holmberg <hans.holmberg@cnexlabs.com>
      Signed-off-by: NJavier González <javier@cnexlabs.com>
      Signed-off-by: NMatias Bjørling <mb@lightnvm.io>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      76758390
    • H
      lightnvm: pblk: check data lines version on recovery · d0ab0b1a
      Hans Holmberg 提交于
      As a preparation for future bumps of data line persistent storage
      versions, we need to start checking the emeta line version during
      recovery. Also slit up the current emeta/smeta version into two
      bytes (major,minor).
      
      Recovering lines with the same major number as the current pblk data
      line version must succeed. This means that any changes in the
      persistent format must be:
      
       (1) Backward compatible: if we switch back to and older
           kernel, recovery of lines stored with major == current_major
           and minor > current_minor must succeed.
      
       (2) Forward compatible: switching to a newer kernel,
           recovery of lines stored with major=current_major and
           minor < minor must handle the data format differences
           gracefully(i.e. initialize new data structures to default values).
      
      If we detect lines that have a different major number than
      the current we must abort recovery. The user must manually
      migrate the data in this case.
      
      Previously the version stored in the emeta header was copied
      from smeta, which has version 1, so we need to set the minor
      version to 1.
      Signed-off-by: NHans Holmberg <hans.holmberg@cnexlabs.com>
      Signed-off-by: NJavier González <javier@cnexlabs.com>
      Signed-off-by: NMatias Bjørling <mb@lightnvm.io>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      d0ab0b1a
    • H
      lightnvm: pblk: handle bad sectors in the emeta area correctly · cfe1c9e2
      Hans Holmberg 提交于
      Unless we check if there are bad sectors in the entire emeta-area
      we risk ending up with valid bitmap / available sector count inconsistency.
      This results in lines with a bad chunk at the last LUN marked as bad,
      so go through the whole emeta area and mark up the invalid sectors.
      Signed-off-by: NHans Holmberg <hans.holmberg@cnexlabs.com>
      Signed-off-by: NMatias Bjørling <mb@lightnvm.io>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      cfe1c9e2
  2. 05 1月, 2018 4 次提交
  3. 22 11月, 2017 1 次提交
  4. 13 10月, 2017 22 次提交
  5. 08 7月, 2017 1 次提交
  6. 01 7月, 2017 4 次提交
  7. 27 6月, 2017 4 次提交