Which version of xfs-progs to use on Debian?

Which version of xfs-progs to use on Debian?

[John Henderson]

Hi,

I'm trying to determine the optimal combination of kernel version and
xfs-progs version to use on a Debian Jessie system (for amd64).

I've searched this mailing list, and noticed the following exchange:

  http://www.spinics.net/lists/xfs/msg36165.html

specifically, Dave's response:

  "As it is, in future the version of xfsprogs will tell you what
kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly
the same code/feature support as kernel 4.2.0. Similarly for
xfsprogs/kernel 4.3.0."

I'm also aware that prior to xfsprogs 4.2.0, userspace versioning did
not match kernel numbering, as noted:

  https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags
  https://www.spinics.net/lists/xfs/msg33984.html

So, as I understand the situation, xfsprogs 3.2.x was associated with
a lot of different 3.x and 4.y (y<2) kernels.  Further, I want to make
sure to take advantage of all the (current and future) reliability
improvements of the new xfs v5 on-disk format, which means (from what
I follow) that I need at least kernel 3.15 and xfsprogs 3.2.0, as seen
here:

  https://www.spinics.net/lists/xfs/msg27961.html

My main concern focuses on the options currently available in Debian
(primarily Jessie + backports).  Here's the matchup of what Debian
ships (jessie, jessie-bpo, and stretch):

                      linux-kernel     xfs-progs
Jessie:               3.16.36          3.2.1
Jessie Backports:     4.7.8            4.3.0
Stretch:              4.8.5            4.3.0

So, at first pass, I could just use native jessie's kernel 3.16.36 and
xfsprogs 3.2.1 (and they seem to match well, as they were released
together).  However, I actually have to use a more recent kernel
anyway for some SkyLake support issues.  So, that takes us to at least
kernel 4.7.8.  I note, though, that jessie-backports is *not*
packaging xfsprogs 4.7 alongside its kernel (but instead xfsprogs
4.3.0); similar issues exist for the 4.8.5 kernel from stretch.

Assuming I stick to binary packages distributed through the official
Debian repos, what's the recommendation of the xfs experts: would I be
better off (in terms of reliability) with xfsprogs 3.2.1 or xfsprogs
4.3.0 used with kernel 4.7.8?  As an alternative, would it be even
better for me to use xfsprogs 4.7 (via compiling from source, even
though I'd rather not)?

Also, what are current best-practice parameters for 'mkfs.xfs' in
order to optimize reliability?  Filesystem size is ~10 TB on top of
LUKS-encrypted Software RAID-1 (using enterprise 512e drives).

I'd assume, we'd at least want the following:

  -m crc=1 finobt=1

Any pointers to a good write-up on optimizing such creation (and
later, mount-time) decisions?

Thanks so much (and for all your work on XFS, too).

-John

Re: Which version of xfs-progs to use on Debian?

[Brian Foster]

On Mon, Nov 14, 2016 at 01:23:50AM -0600, John Henderson wrote:
> Hi,
> 
> I'm trying to determine the optimal combination of kernel version and
> xfs-progs version to use on a Debian Jessie system (for amd64).
> 
> I've searched this mailing list, and noticed the following exchange:
> 
>   http://www.spinics.net/lists/xfs/msg36165.html
> 
> specifically, Dave's response:
> 
>   "As it is, in future the version of xfsprogs will tell you what
> kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly
> the same code/feature support as kernel 4.2.0. Similarly for
> xfsprogs/kernel 4.3.0."
> 
> I'm also aware that prior to xfsprogs 4.2.0, userspace versioning did
> not match kernel numbering, as noted:
> 
>   https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags
>   https://www.spinics.net/lists/xfs/msg33984.html
> 
> So, as I understand the situation, xfsprogs 3.2.x was associated with
> a lot of different 3.x and 4.y (y<2) kernels.  Further, I want to make
> sure to take advantage of all the (current and future) reliability
> improvements of the new xfs v5 on-disk format, which means (from what
> I follow) that I need at least kernel 3.15 and xfsprogs 3.2.0, as seen
> here:
> 
>   https://www.spinics.net/lists/xfs/msg27961.html
> 
> My main concern focuses on the options currently available in Debian
> (primarily Jessie + backports).  Here's the matchup of what Debian
> ships (jessie, jessie-bpo, and stretch):
> 
>                       linux-kernel     xfs-progs
> Jessie:               3.16.36          3.2.1
> Jessie Backports:     4.7.8            4.3.0
> Stretch:              4.8.5            4.3.0
> 
> So, at first pass, I could just use native jessie's kernel 3.16.36 and
> xfsprogs 3.2.1 (and they seem to match well, as they were released
> together).  However, I actually have to use a more recent kernel
> anyway for some SkyLake support issues.  So, that takes us to at least
> kernel 4.7.8.  I note, though, that jessie-backports is *not*
> packaging xfsprogs 4.7 alongside its kernel (but instead xfsprogs
> 4.3.0); similar issues exist for the 4.8.5 kernel from stretch.
> 

Others might be able to chime in on this, but that strikes me as a
packaging issue. My understanding is that the marriage between the
kernel revision and xfsprogs revision tracking numbers is to help define
dependencies between the two. That said, it might not be a problem for
you if you aren't using anything notable introduced between 4.3 and 4.7.

> Assuming I stick to binary packages distributed through the official
> Debian repos, what's the recommendation of the xfs experts: would I be
> better off (in terms of reliability) with xfsprogs 3.2.1 or xfsprogs
> 4.3.0 used with kernel 4.7.8?  As an alternative, would it be even
> better for me to use xfsprogs 4.7 (via compiling from source, even
> though I'd rather not)?
> 

v4.7 of xfsprogs is probably best, but IMO, you'll probably be fine with
the v4.3 in the simple cases (you haven't mentioned whether you're
planning to use xfsprogs for anything beyond mkfs and possibly repair if
something goes wrong). Just keep in mind that it is out of date with
respect to your kernel in the event that you do run into problems down
the road and may want to update.

> Also, what are current best-practice parameters for 'mkfs.xfs' in
> order to optimize reliability?  Filesystem size is ~10 TB on top of
> LUKS-encrypted Software RAID-1 (using enterprise 512e drives).
> 
> I'd assume, we'd at least want the following:
> 
>   -m crc=1 finobt=1
> 

Usually it is best to go with defaults. Indeed, crc=1,finobt=1 are both
defaults and have been for a while now. See commit 566ebd5a ("mkfs:
default to CRC enabled filesystems") which first appeared in xfsprogs
v3.2.3. I'm not aware of any special/magic options required for raid1 or
encryption.

Brian

> Any pointers to a good write-up on optimizing such creation (and
> later, mount-time) decisions?
> 
> Thanks so much (and for all your work on XFS, too).
> 
> -John
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Which version of xfs-progs to use on Debian?

[John Henderson]

Hi Brian,

Thanks for your prompt response.  More inline.

On Mon, Nov 14, 2016 at 7:14 AM, Brian Foster <bfoster@redhat.com> wrote:
> On Mon, Nov 14, 2016 at 01:23:50AM -0600, John Henderson wrote:
>> Hi,
>>
>> I'm trying to determine the optimal combination of kernel version and
>> xfs-progs version to use on a Debian Jessie system (for amd64).
>>
>> I've searched this mailing list, and noticed the following exchange:
>>
>>   http://www.spinics.net/lists/xfs/msg36165.html
>>
>> specifically, Dave's response:
>>
>>   "As it is, in future the version of xfsprogs will tell you what
>> kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly
>> the same code/feature support as kernel 4.2.0. Similarly for
>> xfsprogs/kernel 4.3.0."
>>
>> I'm also aware that prior to xfsprogs 4.2.0, userspace versioning did
>> not match kernel numbering, as noted:
>>
>>   https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags
>>   https://www.spinics.net/lists/xfs/msg33984.html
>>
>> So, as I understand the situation, xfsprogs 3.2.x was associated with
>> a lot of different 3.x and 4.y (y<2) kernels.  Further, I want to make
>> sure to take advantage of all the (current and future) reliability
>> improvements of the new xfs v5 on-disk format, which means (from what
>> I follow) that I need at least kernel 3.15 and xfsprogs 3.2.0, as seen
>> here:
>>
>>   https://www.spinics.net/lists/xfs/msg27961.html
>>
>> My main concern focuses on the options currently available in Debian
>> (primarily Jessie + backports).  Here's the matchup of what Debian
>> ships (jessie, jessie-bpo, and stretch):
>>
>>                       linux-kernel     xfs-progs
>> Jessie:               3.16.36          3.2.1
>> Jessie Backports:     4.7.8            4.3.0
>> Stretch:              4.8.5            4.3.0
>>
>> So, at first pass, I could just use native jessie's kernel 3.16.36 and
>> xfsprogs 3.2.1 (and they seem to match well, as they were released
>> together).  However, I actually have to use a more recent kernel
>> anyway for some SkyLake support issues.  So, that takes us to at least
>> kernel 4.7.8.  I note, though, that jessie-backports is *not*
>> packaging xfsprogs 4.7 alongside its kernel (but instead xfsprogs
>> 4.3.0); similar issues exist for the 4.8.5 kernel from stretch.
>>
>
> Others might be able to chime in on this, but that strikes me as a
> packaging issue.

Agree completely.  I very strongly prefer to use 100% default packages within
single repo in Debian (ie, no pulling from Jessie backports).  However, usage
of the workstation in this case requires support of the Skylake CPU, available
only in more modern 4.x series of kernels (Jessie [stable] is still at 3.16.x).
So, that means pulling some kernel like 4.7.x from Jessie backports.  Oh, well.

> My understanding is that the marriage between the
> kernel revision and xfsprogs revision tracking numbers is to help define
> dependencies between the two.

Yes, I was a bit surprised that Debian testing / unstable have non-matched
kernel / xfsprogs as currently packaged (ie, 4.7 & 4.8 kernels, respectively,
with 4.3 xfsprogs).  Debian stable is indeed matched with kernel 3.16.x and
xfsprogs 3.2.1.  I also noted that the most recent (ie, testing / unstable)
xfsprogs uploads to Debian repos appear to be non-maintainer uploads
(NMUs); perhaps, there's something going on with Debian XFS maintainers?

> That said, it might not be a problem for
> you if you aren't using anything notable introduced between 4.3 and 4.7.

Given that crc / finobt are default, I don't plan on using anything
else, but still
am glad to check with the list, here.  Thanks for your input.

>> Assuming I stick to binary packages distributed through the official
>> Debian repos, what's the recommendation of the xfs experts: would I be
>> better off (in terms of reliability) with xfsprogs 3.2.1 or xfsprogs
>> 4.3.0 used with kernel 4.7.8?  As an alternative, would it be even
>> better for me to use xfsprogs 4.7 (via compiling from source, even
>> though I'd rather not)?
>>
>
> v4.7 of xfsprogs is probably best, but IMO, you'll probably be fine with
> the v4.3 in the simple cases (you haven't mentioned whether you're
> planning to use xfsprogs for anything beyond mkfs and possibly repair if
> something goes wrong).

Yes, plan is only to use xfsprogs for mkfs (+ fsck).  If I'm in the situation
where I have to repair anything, perhaps that's the time to look more carefully
at getting (compiling?) xfsprogs that matches kernel specifically.

> Just keep in mind that it is out of date with
> respect to your kernel in the event that you do run into problems down
> the road and may want to update.
>
>> Also, what are current best-practice parameters for 'mkfs.xfs' in
>> order to optimize reliability?  Filesystem size is ~10 TB on top of
>> LUKS-encrypted Software RAID-1 (using enterprise 512e drives).
>>
>> I'd assume, we'd at least want the following:
>>
>>   -m crc=1 finobt=1
>>
>
> Usually it is best to go with defaults. Indeed, crc=1,finobt=1 are both
> defaults and have been for a while now. See commit 566ebd5a ("mkfs:
> default to CRC enabled filesystems") which first appeared in xfsprogs
> v3.2.3. I'm not aware of any special/magic options required for raid1 or
> encryption.

Yep, saw those changes in the defaults in xfs list announcements.  Thanks
for reiterating.

Take care,
John

Re: Which version of xfs-progs to use on Debian?

[Eric Sandeen]

On 11/14/16 1:23 AM, John Henderson wrote:
> Hi,
> 
> I'm trying to determine the optimal combination of kernel version
> and xfs-progs version to use on a Debian Jessie system (for amd64).

Generally, the package version to use with a distribution are the
ones shipped by the distribution.

> I've searched this mailing list, and noticed the following exchange:
> 
> http://www.spinics.net/lists/xfs/msg36165.html
> 
> specifically, Dave's response:
> 
> "As it is, in future the version of xfsprogs will tell you what 
> kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly 
> the same code/feature support as kernel 4.2.0. Similarly for 
> xfsprogs/kernel 4.3.0."

Yes, but things stay compatible either way

> I'm also aware that prior to xfsprogs 4.2.0, userspace versioning
> did not match kernel numbering, as noted:
> 
> https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags 
> https://www.spinics.net/lists/xfs/msg33984.html
> 
> So, as I understand the situation, xfsprogs 3.2.x was associated
> with a lot of different 3.x and 4.y (y<2) kernels.  Further, I want
> to make sure to take advantage of all the (current and future)
> reliability improvements of the new xfs v5 on-disk format, which
> means (from what I follow) that I need at least kernel 3.15 and
> xfsprogs 3.2.0, as seen here:
> 
> https://www.spinics.net/lists/xfs/msg27961.html

FWIW, crcs became /default/ in 3.2.3:

566ebd5 mkfs: default to CRC enabled filesystems
$ git describe --contains 566ebd5
v3.2.3-rc1~2
 
> My main concern focuses on the options currently available in Debian 
> (primarily Jessie + backports).  Here's the matchup of what Debian 
> ships (jessie, jessie-bpo, and stretch):
> 
> linux-kernel     xfs-progs Jessie:               3.16.36
> 3.2.1 Jessie Backports:     4.7.8            4.3.0 Stretch:
> 4.8.5            4.3.0
> 
> So, at first pass, I could just use native jessie's kernel 3.16.36
> and xfsprogs 3.2.1 (and they seem to match well, as they were
> released together).  However, I actually have to use a more recent
> kernel anyway for some SkyLake support issues.  So, that takes us to
> at least kernel 4.7.8.  I note, though, that jessie-backports is
> *not* packaging xfsprogs 4.7 alongside its kernel (but instead
> xfsprogs 4.3.0); similar issues exist for the 4.8.5 kernel from
> stretch.

that's not really a problem per se.  There is no hard requirement
for xfsprogs version to match.  Version tells you more about the time of
release, and so has a loose notion of "matching features" but it's
far from mandatory to match.

> Assuming I stick to binary packages distributed through the official 
> Debian repos, what's the recommendation of the xfs experts: would I
> be better off (in terms of reliability) with xfsprogs 3.2.1 or
> xfsprogs 4.3.0 used with kernel 4.7.8?  As an alternative, would it
> be even better for me to use xfsprogs 4.7 (via compiling from source,
> even though I'd rather not)?
> 
> Also, what are current best-practice parameters for 'mkfs.xfs' in 
> order to optimize reliability?  Filesystem size is ~10 TB on top of 
> LUKS-encrypted Software RAID-1 (using enterprise 512e drives).
> 
> I'd assume, we'd at least want the following:
> 
> -m crc=1 finobt=1
> 
> Any pointers to a good write-up on optimizing such creation (and 
> later, mount-time) decisions?

http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E
 
> Thanks so much (and for all your work on XFS, too).

Newer kernels and newer xfsprogs will /always/ have more features
and bugfixes than older ones (and, rarely, new regressions).

However, other than very rare deprecations, any userspace/kernelspace
pair will /work/ just fine and be compatible, though not all features
may be available.  (Newer userspace than kernelspace may result in
unmountable filesystems though, if you enable some feature at mkfs time
that isn't supported by your kernel.)

Generally, I'd defer to your distro.  It's presumably what they
test, and what they can support.  If you have specific needs not
met by your distro and need to grab something newer, then you're
largely on your own.  There is no "best" release.

-Eric

Re: Which version of xfs-progs to use on Debian?

[John Henderson]

Eric,

Thanks for the input.  More inline.

On Mon, Nov 14, 2016 at 7:51 AM, Eric Sandeen <sandeen@sandeen.net> wrote:
> On 11/14/16 1:23 AM, John Henderson wrote:
>> Hi,
>>
>> I'm trying to determine the optimal combination of kernel version
>> and xfs-progs version to use on a Debian Jessie system (for amd64).
>
> Generally, the package version to use with a distribution are the
> ones shipped by the distribution.
>
>> I've searched this mailing list, and noticed the following exchange:
>>
>> http://www.spinics.net/lists/xfs/msg36165.html
>>
>> specifically, Dave's response:
>>
>> "As it is, in future the version of xfsprogs will tell you what
>> kernel has the same feature support. i.e. xfsprogs 4.2.0 has exactly
>> the same code/feature support as kernel 4.2.0. Similarly for
>> xfsprogs/kernel 4.3.0."
>
> Yes, but things stay compatible either way

Appreciate you explicitly confirming that.  Thanks!

>> I'm also aware that prior to xfsprogs 4.2.0, userspace versioning
>> did not match kernel numbering, as noted:
>>
>> https://git.kernel.org/cgit/fs/xfs/xfsprogs-dev.git/refs/tags
>> https://www.spinics.net/lists/xfs/msg33984.html
>>
>> So, as I understand the situation, xfsprogs 3.2.x was associated
>> with a lot of different 3.x and 4.y (y<2) kernels.  Further, I want
>> to make sure to take advantage of all the (current and future)
>> reliability improvements of the new xfs v5 on-disk format, which
>> means (from what I follow) that I need at least kernel 3.15 and
>> xfsprogs 3.2.0, as seen here:
>>
>> https://www.spinics.net/lists/xfs/msg27961.html
>
> FWIW, crcs became /default/ in 3.2.3:
>
> 566ebd5 mkfs: default to CRC enabled filesystems
> $ git describe --contains 566ebd5
> v3.2.3-rc1~2

Thanks --- gotcha, and saw the announcement in list archives.

>> My main concern focuses on the options currently available in Debian
>> (primarily Jessie + backports).  Here's the matchup of what Debian
>> ships (jessie, jessie-bpo, and stretch):
>>
>> linux-kernel     xfs-progs Jessie:               3.16.36
>> 3.2.1 Jessie Backports:     4.7.8            4.3.0 Stretch:
>> 4.8.5            4.3.0
>>
>> So, at first pass, I could just use native jessie's kernel 3.16.36
>> and xfsprogs 3.2.1 (and they seem to match well, as they were
>> released together).  However, I actually have to use a more recent
>> kernel anyway for some SkyLake support issues.  So, that takes us to
>> at least kernel 4.7.8.  I note, though, that jessie-backports is
>> *not* packaging xfsprogs 4.7 alongside its kernel (but instead
>> xfsprogs 4.3.0); similar issues exist for the 4.8.5 kernel from
>> stretch.
>
> that's not really a problem per se.  There is no hard requirement
> for xfsprogs version to match.  Version tells you more about the time of
> release, and so has a loose notion of "matching features" but it's
> far from mandatory to match.

Great to know / confirm.  I'd assume more recent xfsprogs are safer to
use given that more bugs have probably been caught than additional
regressions introduced?

>> Assuming I stick to binary packages distributed through the official
>> Debian repos, what's the recommendation of the xfs experts: would I
>> be better off (in terms of reliability) with xfsprogs 3.2.1 or
>> xfsprogs 4.3.0 used with kernel 4.7.8?  As an alternative, would it
>> be even better for me to use xfsprogs 4.7 (via compiling from source,
>> even though I'd rather not)?
>>
>> Also, what are current best-practice parameters for 'mkfs.xfs' in
>> order to optimize reliability?  Filesystem size is ~10 TB on top of
>> LUKS-encrypted Software RAID-1 (using enterprise 512e drives).
>>
>> I'd assume, we'd at least want the following:
>>
>> -m crc=1 finobt=1
>>
>> Any pointers to a good write-up on optimizing such creation (and
>> later, mount-time) decisions?
>
> http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E

Thanks for the link.  I read a good amount of the xfs.org wiki, but wasn't
sure how much to trust that the wiki was particularly up-to-date, as I saw that:

  http://xfs.org/index.php/XFS_Status_Updates

hadn't been updated since 2013, and that predated the v5 on-disk format.
Also:

  http://xfs.org/index.php/XFS_FAQ#Q:_What_mount_options_does_XFS_have.3F

is obviously superceded by more recent changes:

  https://www.spinics.net/lists/xfs/msg33984.html

Anyway, appreciate your pointing me to the FAQ link as still relevant.  I'm
planning to just go with default mkfs and mount options.

>> Thanks so much (and for all your work on XFS, too).
>
> Newer kernels and newer xfsprogs will /always/ have more features
> and bugfixes than older ones (and, rarely, new regressions).
>
> However, other than very rare deprecations, any userspace/kernelspace
> pair will /work/ just fine and be compatible, though not all features
> may be available.

That's what I suspected, but glad to have you (and list) explicitly confirm.

> (Newer userspace than kernelspace may result in
> unmountable filesystems though, if you enable some feature at mkfs time
> that isn't supported by your kernel.)

Yep, I'm tracking that.

> Generally, I'd defer to your distro.  It's presumably what they
> test, and what they can support.

Totally agree.  Unfortunately, need a non-default repo kernel for Intel SkyLake
support.  Thankfully, at least, it's packaged as Debian Jessie backports.  But,
then, that led me to the question of which xfsprogs to use with it.  Seems like
the consensus here (among binary-packaged versions) is to use xfsprogs 4.3.0
with kernel 4.7.8.

> If you have specific needs not
> met by your distro and need to grab something newer, then you're
> largely on your own.  There is no "best" release.

Gotcha.

Thanks again,
John