On Sun, Sep 02, 2012 at 04:43:48AM -0700, Shentino wrote:
I assume the same results are expected during a scrub as during a normal read?
yes
I've tested this on an 2 disk data/raid1, metadata/raid1 with a running
dd over one of the devices continually and using the filesystem. It was
On Wed, Sep 5, 2012 at 8:04 AM, David Sterba d...@jikos.cz wrote:
On Sun, Sep 02, 2012 at 04:43:48AM -0700, Shentino wrote:
I assume the same results are expected during a scrub as during a normal
read?
yes
I've tested this on an 2 disk data/raid1, metadata/raid1 with a running
dd over
Hi,
On 09/02/2012 03:03 AM, Shentino wrote:
This whole subject was also about using sed to corrupt-o-magic a
file's data on disk.
Is this an acceptable method for testing?
I am not sure that doing sed /dev/sdX /dev/sdX ... is the right
thing to do, because it rewrites the full disk. This
On Tue, Sep 4, 2012 at 11:15 AM, Goffredo Baroncelli kreij...@libero.it wrote:
Hi,
On 09/02/2012 03:03 AM, Shentino wrote:
This whole subject was also about using sed to corrupt-o-magic a
file's data on disk.
Is this an acceptable method for testing?
I am not sure that doing sed
On 09/05/2012 03:59 AM, Shentino wrote:
I am not sure that doing sed/dev/sdX/dev/sdX ... is the right thing to
do, because it rewrites the full disk. This means that:
- it takes a lot of time
- you don't have any control about which part of the disk you change: what
happens if sed
On Sat, Sep 1, 2012 at 10:44 PM, David Sterba d...@jikos.cz wrote:
On Sat, Sep 01, 2012 at 06:03:32PM -0700, Shentino wrote:
This whole subject was also about using sed to corrupt-o-magic a
file's data on disk.
Is this an acceptable method for testing?
Starting with kernels 3.4 the error
How effective would it be to directly write to the underlying device
and then running tests to see if the corruption is properly detected?
I just ran a fuzz test by syncing, and then manually corrupting a file
with the help of a surgical sed (yes, the before and after patterns
had fixed equal
Also, since the problem prevented me from syncing my other filesystmes
I couldn't capture the debug info.
It vanished during the cold boot still sitting in dirty page cache.
On Fri, Aug 31, 2012 at 11:44 PM, Shentino shent...@gmail.com wrote:
How effective would it be to directly write to the
Please make sure you are running a very recent kernel. Btrfs is VERY
active and fixes for things like this are going in all the time. Any
related crash errors, kernel oopses, and exact methodology so we can
reproduce would be useful.
dmesg and uname -a would help us triage this and see what we
On Sat, Sep 1, 2012 at 1:59 PM, cwillu cwi...@cwillu.com wrote:
You still haven't said which kernel you were running; the thing to do
is try the very latest rc (if not btrfs-next).
Sorry about that!
I thought I included it.
3.3.8
Hmm...seems it's been EOL'ed. I need to yell at my distro.
It should not. It is always preferred that you dd your drive onto
another disk just in case though.
On Sat, Sep 1, 2012 at 5:31 PM, Shentino shent...@gmail.com wrote:
On Sat, Sep 1, 2012 at 1:59 PM, cwillu cwi...@cwillu.com wrote:
You still haven't said which kernel you were running; the thing
This whole subject was also about using sed to corrupt-o-magic a
file's data on disk.
Is this an acceptable method for testing?
On Sat, Sep 1, 2012 at 4:49 PM, Michael m...@draftx.net wrote:
It should not. It is always preferred that you dd your drive onto
another disk just in case though.
On Sat, Sep 01, 2012 at 06:03:32PM -0700, Shentino wrote:
This whole subject was also about using sed to corrupt-o-magic a
file's data on disk.
Is this an acceptable method for testing?
Starting with kernels 3.4 the error handling has been improved,
namely for the EIO, so it shouldn't take
13 matches
Mail list logo
