| Message ID | 20161010050647.30262-1-wangxg.fnst@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 10/10/16 13:06, Wang Xiaoguang wrote: > For btrfs, if compression is enabled, it may generate inline data for a > blocksize data range, this inline data is stored in fs tree, will not have > a individual extent, try to reflink this data range at a not-zero offset > will return EOPNOTSUPP, so here we disable inline data feature for btrfs. Hm. I didn't get the point of why its not a btrfs bug ? Thanks, Anand > Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com> > --- > tests/generic/175 | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/tests/generic/175 b/tests/generic/175 > index 964580c..b3f90dc 100755 > --- a/tests/generic/175 > +++ b/tests/generic/175 > @@ -50,6 +50,13 @@ rm -f "$seqres.full" > > echo "Format and mount" > _scratch_mkfs > "$seqres.full" 2>&1 > +# For btrfs, if compression is enabled, it may generate inline data for a > +# blocksize data range, this inline data is stored in fs tree, will not have > +# a individual extent, try to reflink this data range at a not-zero offset > +# will return EOPNOTSUPP, so here we disable inline data feature for btrfs. > +if [ "$FSTYP" = "btrfs" ]; then > + export MOUNT_OPTIONS="-o max_inline=0 $MOUNT_OPTIONS" > +fi > _scratch_mount >> "$seqres.full" 2>&1 > > testdir="$SCRATCH_MNT/test-$seq" > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 10, 2016 at 05:03:49PM +0800, Anand Jain wrote: > > > On 10/10/16 13:06, Wang Xiaoguang wrote: > >For btrfs, if compression is enabled, it may generate inline data for a > >blocksize data range, this inline data is stored in fs tree, will not have > >a individual extent, try to reflink this data range at a not-zero offset > >will return EOPNOTSUPP, so here we disable inline data feature for btrfs. > > Hm. I didn't get the point of why its not a btrfs bug ? /me was wondering about that too -- if you try to reflink an inlinedata file, the reflink just fails? I guess that's not totally unreasonable for the normal usecase (reflink copy) since the copy will probably end up being inlinedata too. OTOH it's a little surprising that reflinking a portion of a file at a non-zero offset (i.e. non-copy reflink) like we're doing here doesn't convert the file to non-inline and fails instead. --D > > Thanks, Anand > > > >Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com> > >--- > > tests/generic/175 | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > >diff --git a/tests/generic/175 b/tests/generic/175 > >index 964580c..b3f90dc 100755 > >--- a/tests/generic/175 > >+++ b/tests/generic/175 > >@@ -50,6 +50,13 @@ rm -f "$seqres.full" > > > > echo "Format and mount" > > _scratch_mkfs > "$seqres.full" 2>&1 > >+# For btrfs, if compression is enabled, it may generate inline data for a > >+# blocksize data range, this inline data is stored in fs tree, will not have > >+# a individual extent, try to reflink this data range at a not-zero offset > >+# will return EOPNOTSUPP, so here we disable inline data feature for btrfs. > >+if [ "$FSTYP" = "btrfs" ]; then > >+ export MOUNT_OPTIONS="-o max_inline=0 $MOUNT_OPTIONS" > >+fi > > _scratch_mount >> "$seqres.full" 2>&1 > > > > testdir="$SCRATCH_MNT/test-$seq" > > > -- > To unsubscribe from this list: send the line "unsubscribe fstests" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 10, 2016 at 01:06:47PM +0800, Wang Xiaoguang wrote: > For btrfs, if compression is enabled, it may generate inline data for a > blocksize data range, this inline data is stored in fs tree, will not have > a individual extent, try to reflink this data range at a not-zero offset > will return EOPNOTSUPP, so here we disable inline data feature for btrfs. > > Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com> > --- > tests/generic/175 | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/tests/generic/175 b/tests/generic/175 > index 964580c..b3f90dc 100755 > --- a/tests/generic/175 > +++ b/tests/generic/175 > @@ -50,6 +50,13 @@ rm -f "$seqres.full" > > echo "Format and mount" > _scratch_mkfs > "$seqres.full" 2>&1 > +# For btrfs, if compression is enabled, it may generate inline data for a > +# blocksize data range, this inline data is stored in fs tree, will not have > +# a individual extent, try to reflink this data range at a not-zero offset > +# will return EOPNOTSUPP, so here we disable inline data feature for btrfs. > +if [ "$FSTYP" = "btrfs" ]; then > + export MOUNT_OPTIONS="-o max_inline=0 $MOUNT_OPTIONS" > +fi Can we /please stop/ putting special case code like this in tests? This is an unsustainable and unmaintainable practice - it's making a mess of the test code. If there are specific mount options that needs to be avoided, then add an option to filter them out. e.g. something like this: _scratch_options_filter btrfs compress so that it removes any compression option from the btrfs mount/mkfs that is run for that test. Cheers, Dave.
hi, On 10/11/2016 07:09 AM, Dave Chinner wrote: > On Mon, Oct 10, 2016 at 01:06:47PM +0800, Wang Xiaoguang wrote: >> For btrfs, if compression is enabled, it may generate inline data for a >> blocksize data range, this inline data is stored in fs tree, will not have >> a individual extent, try to reflink this data range at a not-zero offset >> will return EOPNOTSUPP, so here we disable inline data feature for btrfs. >> >> Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com> >> --- >> tests/generic/175 | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/tests/generic/175 b/tests/generic/175 >> index 964580c..b3f90dc 100755 >> --- a/tests/generic/175 >> +++ b/tests/generic/175 >> @@ -50,6 +50,13 @@ rm -f "$seqres.full" >> >> echo "Format and mount" >> _scratch_mkfs > "$seqres.full" 2>&1 >> +# For btrfs, if compression is enabled, it may generate inline data for a >> +# blocksize data range, this inline data is stored in fs tree, will not have >> +# a individual extent, try to reflink this data range at a not-zero offset >> +# will return EOPNOTSUPP, so here we disable inline data feature for btrfs. >> +if [ "$FSTYP" = "btrfs" ]; then >> + export MOUNT_OPTIONS="-o max_inline=0 $MOUNT_OPTIONS" >> +fi > Can we /please stop/ putting special case code like this in tests? > > This is an unsustainable and unmaintainable practice - it's making a > mess of the test code. If there are specific mount options that > needs to be avoided, then add an option to filter them out. e.g. > something like this: > > _scratch_options_filter btrfs compress > > so that it removes any compression option from the btrfs mount/mkfs > that is run for that test. OK, I see, thanks. Regards, Xiaoguang Wang > > Cheers, > > Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/tests/generic/175 b/tests/generic/175 index 964580c..b3f90dc 100755 --- a/tests/generic/175 +++ b/tests/generic/175 @@ -50,6 +50,13 @@ rm -f "$seqres.full" echo "Format and mount" _scratch_mkfs > "$seqres.full" 2>&1 +# For btrfs, if compression is enabled, it may generate inline data for a +# blocksize data range, this inline data is stored in fs tree, will not have +# a individual extent, try to reflink this data range at a not-zero offset +# will return EOPNOTSUPP, so here we disable inline data feature for btrfs. +if [ "$FSTYP" = "btrfs" ]; then + export MOUNT_OPTIONS="-o max_inline=0 $MOUNT_OPTIONS" +fi _scratch_mount >> "$seqres.full" 2>&1 testdir="$SCRATCH_MNT/test-$seq"
For btrfs, if compression is enabled, it may generate inline data for a blocksize data range, this inline data is stored in fs tree, will not have a individual extent, try to reflink this data range at a not-zero offset will return EOPNOTSUPP, so here we disable inline data feature for btrfs. Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com> --- tests/generic/175 | 7 +++++++ 1 file changed, 7 insertions(+)