On 2014-Jan-05 09:11:38 +0100, "O. Hartmann" <ohartman_at_zedat.fu-berlin.de> wrote: >On Sun, 5 Jan 2014 10:14:26 +1100 >Peter Jeremy <peter_at_rulingia.com> wrote: > >> On 2014-Jan-04 23:26:42 +0100, "O. Hartmann" >> <ohartman_at_zedat.fu-berlin.de> wrote: >> >zfs list -r BACKUP00 >> >NAME USED AVAIL REFER MOUNTPOINT >> >BACKUP00 1.48T 1.19T 144K /BACKUP00 >> >BACKUP00/backup 1.47T 1.19T 1.47T /backup >> >> Well, that at least shows it's making progress - it's gone from 2.5T >> to 1.47T used (though I gather that has taken several days). Can you >> pleas post the result of >> zfs get all BACKUP00/backup >BACKUP00/backup dedup on local This is your problem. Before it can free any block, it has to check for other references to the block via the DDT and I suspect you don't have enough RAM to cache the DDT. Your options are: 1) Wait until the delete finishes. 2) Destroy the pool with extreme prejudice: Forcably export the pool (probably by booting to single user and not starting ZFS) and write zeroes to the first and last MB of ada3p1. BTW, this problem will occur on any filesystem where you've ever enabled dedup - once there are any dedup'd blocks in a filesystem, all deletes need to go via the DDT. -- Peter Jeremy
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:46 UTC