Peter Jeremy wrote:
On 2012-Nov-02 09:30:04 -, Steven Hartland kill...@multiplay.co.uk wr=
ote:
From: Peter Jeremy pe...@rulingia.com
Many years ago, I wrote a simple utility that fills a raw disk with
a pseudo-random sequence and then verifies it. This sort of tool
Sounds useful,
On 2012-Nov-02 09:30:04 -, Steven Hartland kill...@multiplay.co.uk wrote:
From: Peter Jeremy pe...@rulingia.com
Many years ago, I wrote a simple utility that fills a raw disk with
a pseudo-random sequence and then verifies it. This sort of tool
Sounds useful, got a link?
Sorry, no. I
- Original Message -
From: Peter Jeremy pe...@rulingia.com
On 2012-Nov-01 13:29:34 -, Steven Hartland kill...@multiplay.co.uk wrote:
After destroying and re-creating the pool and then writing
zeros to the disk in multiple files without filling the fs
I've manged to reproduce the
Copying in freebsd-scsi@ for visability.
- Original Message -
From: Steven Hartland
Ok after revisiting all the facts and spotting that
the corruption only seemed to happen after my zpool
was nearly full I came up with a wild idea, could
the corruption be being caused by writes after
After destroying and re-creating the pool and then writing
zeros to the disk in multiple files without filling the fs
I've manged to reproduce the corruption again so we can
rule out full disk as the cause.
I'm now testing different senarios to try and identify the
culprit, first test is
On 2012-Nov-01 13:29:34 -, Steven Hartland kill...@multiplay.co.uk wrote:
After destroying and re-creating the pool and then writing
zeros to the disk in multiple files without filling the fs
I've manged to reproduce the corruption again so we can
rule out full disk as the cause.
Many years
Ok after revisiting all the facts and spotting that
the corruption only seemed to happen after my zpool
was nearly full I came up with a wild idea, could
the corruption be being caused by writes after 2TB?
A few command lines latter and this was confirmed
writes to the 3TB disks under mfi are
Message -
From: Steven Hartland ste...@multiplay.co.uk
To: freebsd-stable@freebsd.org; freebsd...@freebsd.org
Sent: Wednesday, October 31, 2012 5:25 PM
Subject: ZFS corruption due to lack of space?
Been running some tests on new hardware here to verify all
is good. One of the tests was to fill
On Wed, Oct 31, 2012 at 10:55 AM, Steven Hartland
kill...@multiplay.co.uk wrote:
At that point with the test seemingly successful I went
to delete test files which resulted in:-
rm random*
rm: random1: Unknown error: 122
ZFS is a logging filesystem. Even removing a file apparently requires
On 2012-Oct-31 17:25:09 -, 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
On Wed, Oct 31, 2012 at 4:48 PM, Artem Belevich a...@freebsd.org wrote:
One way out of this jam is to try truncating some large file in place.
Make sure that file is not part of any snapshot.
Something like this may do the trick:
#dd if=/dev/null of=existing_large_file
Or, perhaps even
On 2012-Oct-31 17:25:09 -, 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
12 matches
Mail list logo
