On Thu, 9 Dec 2010, Lukas Czerner wrote:
> On Wed, 8 Dec 2010, Eric Sandeen wrote:
>
> > On 11/26/10 8:12 AM, Lukas Czerner wrote:
> > > FITRIM ioctl is used on a mounted filesystem to discard (or "trim")
> > > blocks which are not in use by the filesystem. This is useful for
> > > solid-state drives (SSDs) and thinly-provi-sioned storage. This test
> > > helps to verify filesystem FITRIM implementation to assure that it
> > > does not corrupts data.
> > >
> > > This test creates checksums of all files in /usr/share/doc directory and
> > > run several processes which clear its working directory on SCRATCH_MNT,
> > > then copy everything from /usr/share/doc into its working directory, create
> > > list of files in working directory and its checksums and compare it with the
> > > original list of checksums. Every process works in the loop so it repeat
> > > remove->copy->check, while fstrim tool is running simultaneously.
> > >
> > > Fstrim is just a helper tool which uses FITRIM ioctl to actually do the
> > > filesystem discard.
> > >
> > > I found this very useful because when the FITRIM is really buggy (thus
> > > data-destroying) the 248 test will notice, because checksums will most
> > > likely change.
> > >
> > > Signed-off-by: Lukas Czerner <lczerner@xxxxxxxxxx>
>
> -snip-
>
> > > +
> > > +fstrim_loop()
> > > +{
> > > + trap "_destroy_fstrim; exit \$status" 2 15
> > > + fsize=$(df | grep $SCRATCH_MNT | grep $SCRATCH_DEV | awk '{print $2}')
> > > +
> > > + while true ; do
> > > + step=1048576
> > > + start=0
> > > + $here/src/fstrim $SCRATCH_MNT &
> > > + fpid=$!
> > > + wait $fpid
> > > + while [ $start -lt $fsize ] ; do
> > > + $here/src/fstrim -s ${start}k -l ${step}k $SCRATCH_MNT &
> > > + fpid=$!
> > > + wait $fpid
> > > + start=$(( $start + $step ))
> > > + done
> >
> > I may be dense here but
> >
> > a) why do you background and then immediately wait?
> > b) does this start a whole-device trim followed by several
> > smaller range-trims?
I forgot about this one. The reason for this is, that this way we can
get better test coverage of the kernel code, because the code path of
smaller trims (especially not ag-aligned) might be slightly different,
so we test that case as well.
-Lukas
> >
> > I could do with some comments, I suppose.
>
> Hi Eric,
>
> all the waiting is done because Bash is incredibly stupid. As you know,
> fstrim_loop is run at background and when the test is over, or when it
> is killed (with ^C), because of trap, it tries to kill fstrim_loop.
> However, it does not kill currently running commands, so fstrim might be
> still running making it impossible to umount the SCRATCH_MNT.
>
> So this way, I can kill the running process directly. I believe I am not
> the first one running into this troubles, so maybe there is a better way
> ?
>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
