[Ocfs2-devel] [PATCH] Treat writes as new when holes span across page boundaries
Joel Becker
jlbec at evilplan.org
Mon Feb 28 11:40:21 PST 2011
On Mon, Feb 28, 2011 at 01:07:21PM -0600, Goldwyn Rodrigues wrote:
> On Mon, Feb 28, 2011 at 12:03 PM, Joel Becker <jlbec at evilplan.org> wrote:
> > On Wed, Feb 23, 2011 at 04:31:25PM -0600, Goldwyn Rodrigues wrote:
> >> Here is a simple script. I will incorporate later into tailtest later.
> >>
> >> FILENAME=/mnt/f2
> >>
> >> for i in `seq 0 256`; do
> >> let s=$i*4096
> >> echo "a" | dd of=$FILENAME count=1 bs=1 seek=$s conv=notrunc 2>/dev/null
> >> let t=$s+4095
> >> echo "b" | dd of=$FILENAME count=1 bs=1 seek=$t conv=notrunc 2>/dev/null
> >> done
> >
> > You shouldn't need to do 256 runs. I would like to see directed
> > tests that just hit one spot in a file and expose the corruption. For
> > example, your described problem case should work like so:
> >
> > # Write the first three blocks of the file, getting us past inline_data
> > dd if=/dev/urandom of=$FILENAME count=3 bs=4096
> > # Write a byte in the next page
> > dd if=/dev/urandom of=$FILENAME count=1 bs=1 seek=12228 conv=notrunc
> > # Write after some partial-block portion, trying to expose failed zeroing
> > dd if=/dev/urandom of=$FILENAME count=4084 bs=1 seek=12300 conv=notrunc
> >
> > I would expect this to expose the problem as you've described for
> > clustersize >= 8K.
>
>
> Yes, that will work as well, as long as you can differentiate between
> the random characters from urandom and the (unexpected) non-zero
> characters in the (userspace) holes. You can read the data from
> [12229-12299] in the file you have created and check for zeros.
You're right about the urandom being bad for this. Maybe it
should be zeros. But still.
> If you don't want too many changes - s/256/3/ in the script I posted
> and check for the 4th block.
I do want too many changes. Your loop doesn't directly specify
the parameters.
Joel
--
"I'm so tired of being tired,
Sure as night will follow day.
Most things I worry about
Never happen anyway."
http://www.jlbec.org/
jlbec at evilplan.org
More information about the Ocfs2-devel
mailing list