linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Fasheh <mfasheh@suse.de>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: David Sterba <dsterba@suse.com>, btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Idea on compatibility for old distributions
Date: Mon, 9 May 2016 18:52:11 -0700	[thread overview]
Message-ID: <20160510015211.GC7633@wotan.suse.de> (raw)
In-Reply-To: <d527a25c-c1f5-1329-1ed7-c84229a50251@cn.fujitsu.com>

On Tue, May 10, 2016 at 09:16:04AM +0800, Qu Wenruo wrote:
> In the recent test for new btrfs-convert backward compatibility, I
> found that cmds-fi-du.c uses FIEMAP_EXTENT_SHARED bits, which is not
> present in kernel of old distributions like RHEL6 (Sorry, didn't
> test on openSUSE equivalent).
> 
> Unlike e2fsprogs, we can check its version with pkgconfig, any idea
> to avoid such compiling error?

#ifndef FIEMAP_EXTENT_SHARED
#define FIEMAP_EXTENT_SHARED           0x00002000
#endif

This is what I do in duperemove. Many distributions dind't update their
kernel header packages for that bit so even though it's in the kernel
userspace programs using it won't compile.


> And further more, without kernel support for FIEMAP_EXTENT_SHARED,
> will fi-du work anymore?

RHEL6 says they're using 2.6.32 which is just before the introduction of
SHARED. It couild be that they have it though considering there is an
immense number of backports done for distro kernels. I would honestly check
the source. What we're really looking to see is what version of btrfs they
have.

With the above patch we would compile and run everywhere. If someone runs an
obsolete version of btrfs then fi du won't report any shared extents. This
is unfortunate but so is running btrfs from 2.6.32.
	--Mark

--
Mark Fasheh

  reply	other threads:[~2016-05-10  1:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  1:16 Idea on compatibility for old distributions Qu Wenruo
2016-05-10  1:52 ` Mark Fasheh [this message]
2016-05-10  2:04   ` Qu Wenruo
2016-05-10 20:23 ` Eric Sandeen
     [not found]   ` <15f7b634-f173-d73f-5c17-8d9294f1efd7@cn.fujitsu.com>
     [not found]     ` <20160512083755.GJ29353@suse.cz>
2016-05-12  8:51       ` Qu Wenruo
2016-05-12  9:22         ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160510015211.GC7633@wotan.suse.de \
    --to=mfasheh@suse.de \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).