ZFS command can block the whole ZFS subsystem!

O. Hartmann ohartman at zedat.fu-berlin.de
Sun Jan 5 08:46:10 UTC 2014


On Sun, 5 Jan 2014 19:30:39 +1100
Peter Jeremy <peter at rulingia.com> wrote:

> 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.
> 

As I stated earlier in the this thread, the box in question has 32 GB
RAM and this should be sufficient.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140105/5d3cb94f/attachment.sig>


More information about the freebsd-current mailing list