Date: Thu, 1 Nov 2012 08:23:46 +1100 From: Peter Jeremy <peter@rulingia.com> To: Steven Hartland <steven@multiplay.co.uk> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: ZFS corruption due to lack of space? Message-ID: <20121031212346.GL3309@server.rulingia.com> In-Reply-To: <27087376D1C14132A3CC1B4016912F6D@multiplay.co.uk>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 2012-Oct-31 17:25:09 -0000, Steven Hartland <steven@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@opensolaris.org -- Peter Jeremy [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCRluIACgkQ/opHv/APuIf5XwCePbniJH+FqKmFdUYvRlHobjbE U74AoIBMqgc6dVkhg9Znx5K9IVh4Spa2 =1SD/ -----END PGP SIGNATURE-----help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121031212346.GL3309>