ZFS corruption due to lack of space?

[Peter Jeremy]

On 2012-Oct-31 17:25:09 -0000, Steven Hartland <steven at multiplay.co.uk> wrote:
>Been running some tests on new hardware here to verify all
>is good. One of the tests was to fill the zfs array which
>seems like its totally corrupted the tank.

I've accidently "filled" a pool, and had multiple processes try to
write to the full pool, without either emptying the free space reserve
(so I could still delete the offending files) or corrupting the pool.

Had you tried to read/write the raw disks before you tried the
ZFS testing?  Do you have compression and/or dedupe enabled on
the pool?

>1. Given the information it seems like the multiple writes filling
>the disk may have caused metadata corruption?

I don't recall seeing this reported before.

>2. Is there anyway to stop the scrub?

Other than freeing up some space, I don't think so.  If this is a test
pool that you don't need, you could try destroying it and re-creating
it - that may be quicker and easier than recovering the existing pool.

>3. Surely low space should never prevent stopping a scrub?

As Artem noted, ZFS is a copy-on-write filesystem.  It is supposed to
reserve some free space to allow metadata updates (stop scrubs, delete
files, etc) even when it is "full" but I have seen reports of this not
working correctly in the past.  A truncate-in-place may work.

You could also try asking on zfs-discuss at opensolaris.org 

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20121101/d97b6f8b/attachment.sig>