On 2012-Oct-31 17:25:09 -0000, Steven Hartland <ste...@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-disc...@opensolaris.org -- Peter Jeremy
pgptbOF1VVAh4.pgp
Description: PGP signature
