Re: [PATCH] btrfs: test if rename handles dir item collision correctly

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



Eryu Guan <guan@xxxxxxx> 於 2020年11月29日 週日 下午3:22寫道:

>
> On Thu, Nov 26, 2020 at 06:50:13PM +0800, ethanwu wrote:
> > This is a regression test for the issue fixed by the kernel commit titled
> > "Btrfs: correctly calculate item size used when item key collision happends"
> >
> > In this case, we'll simply rename many forged filename that cause collision
> > under a directory to see if rename failed and filesystem is forced readonly.
> >
> > Signed-off-by: ethanwu <ethanwu@xxxxxxxxxxxx>
> > ---
> >  tests/btrfs/227     | 311 ++++++++++++++++++++++++++++++++++++++++++++
> >  tests/btrfs/227.out |   2 +
> >  tests/btrfs/group   |   1 +
> >  3 files changed, 314 insertions(+)
> >  create mode 100755 tests/btrfs/227
> >  create mode 100644 tests/btrfs/227.out
> >
> > diff --git a/tests/btrfs/227 b/tests/btrfs/227
> > new file mode 100755
> > index 00000000..ba1cd359
> > --- /dev/null
> > +++ b/tests/btrfs/227
> > @@ -0,0 +1,311 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2020 Synology.  All Rights Reserved.
> > +#
> > +# FS QA Test 227
> > +#
> > +# Test if btrfs rename handle dir item collision correctly
> > +# Without patch fix, rename will fail with EOVERFLOW, and filesystem
> > +# is forced readonly.
> > +#
> > +# This bug is going to be fxied by a patch for kernel titled
> > +# "Btrfs: correctly calculate item size used when item key collision happends"
> > +#
> > +seq=`basename $0`
> > +seqres=$RESULT_DIR/$seq
> > +echo "QA output created by $seq"
> > +
> > +here=`pwd`
> > +tmp=/tmp/$$
> > +status=1     # failure is the default!
> > +trap "_cleanup; exit \$status" 0 1 2 3 15
> > +
> > +_cleanup()
> > +{
> > +    cd /
> > +    rm -f $tmp.*
> > +}
> > +
> > +# get standard environment, filters and checks
> > +. ./common/rc
> > +. ./common/filter
> > +
> > +# real QA test starts here
> > +
> > +_supported_fs btrfs
> > +_require_scratch
> > +
> > +rm -f $seqres.full
> > +
> > +# Currently in btrfs the node/leaf size can not be smaller than the page
> > +# size (but it can be greater than the page size). So use the largest
> > +# supported node/leaf size (64Kb) so that the test can run on any platform
> > +# that Linux supports.
> > +_scratch_mkfs "--nodesize 65536" >>$seqres.full 2>&1
> > +_scratch_mount
> > +
> > +file_name_list=(d6d0dIka505ebc681949a25a3f1a4e7464f18bfcdb04a103b8ece40cddf61ccc9e690232878008edceecda8633591197bce8c0105891d2717425cb4bd04223bb08426de820da732c0e16b8a9fa236bb5b5260e526639780dacd378ca79428f640a0300a11a98f4f92719c62d6f7d756fa80f0aa654ae06
>
> The file names are too long for the test, I'm wondering how are the
> names that could cause collisions generated in the first place? Is it
> possible to re-generate them at runtime? Instead of hard-coding them in
> the array.
>
> Thanks,
> Eryu

I use the following script to generate the names
https://raw.githubusercontent.com/wutzuchieh/misc_tools/master/crc32_forge.py
but skip names with unprintable characters.

The total available spaces could not be divided evenly to have the
same file length,
and this script could only be used to generate filename of the same length.
Different length would result in different crc32, but I haven't figured out why.
Therefore, I use btrfs-crc -c <desired crc> -l <length> to generate
the last 2 names which don't
have equal length with the previous ones. The last procedure indeed
took a while to run.
Hard-coded names would make time spent on the test more predictable.

thanks,
ethanwu




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux