[REVIEW] Don't make lazy counters default for mkfs

[REVIEW] Don't make lazy counters default for mkfs

[Barry Naujok]

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

Lazy superblock counters was released into mainline in 2.6.23-rc1. Some  
distros are still running an older kernel (2.6.22 for example) and with  
the latest xfsprogs, cannot mount a freshly made filesystem with default  
options.

This patch make lazy counters default back to off now.

Users who have a more recent kernel can easily enable them with mkfs or  
xfs_admin -c1 (in a patch posted out a few days ago which will be in the  
same xfsprogs release as this patch).

Lazy counters will default to on again in xfsprogs 2.10.0 (when CI support  
is released). This should give enough time for distro kernels to catch up.

Barry.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: default_lazycount_off.patch --]
[-- Type: text/x-patch; name=default_lazycount_off.patch, Size: 440 bytes --]

Index: ci/xfsprogs/mkfs/xfs_mkfs.c
===================================================================
--- ci.orig/xfsprogs/mkfs/xfs_mkfs.c	2008-02-28 12:02:55.000000000 +1100
+++ ci/xfsprogs/mkfs/xfs_mkfs.c	2008-02-28 12:04:17.288809770 +1100
@@ -730,7 +730,7 @@
 	nodsflag = norsflag = 0;
 	force_overwrite = 0;
 	worst_freelist = 0;
-	lazy_sb_counters = 1;
+	lazy_sb_counters = 0;
 	bzero(&fsx, sizeof(fsx));
 
 	bzero(&xi, sizeof(xi));

Re: [REVIEW] Don't make lazy counters default for mkfs

[Nathan Scott]

On Thu, 2008-02-28 at 12:09 +1100, Barry Naujok wrote:
> 
> 
> Lazy superblock counters was released into mainline in 2.6.23-rc1.
> Some  
> distros are still running an older kernel (2.6.22 for example) and
> with  

(many distros?  RHEL5 and SLES10 wont have such recent kernels yet,
right?)

> the latest xfsprogs, cannot mount a freshly made filesystem with
> default  
> options.
> 
> This patch make lazy counters default back to off now.

Looks good, thanks.

> Users who have a more recent kernel can easily enable them with mkfs
> or  
> xfs_admin -c1 (in a patch posted out a few days ago which will be in
> the  
> same xfsprogs release as this patch).
> 
> Lazy counters will default to on again in xfsprogs 2.10.0 (when CI
> support  
> is released). This should give enough time for distro kernels to catch
> up.

Hmm, that still seems pretty soon to me.  I'd have thought you'd at
least want to wait until most of the distributions (esp. SUSE for you
guys) have released versions that have kernels sufficiently recent
that the default mkfs will work.  Otherwise this will be a recurring
problem.

cheers.

-- 
Nathan

Re: [REVIEW] Don't make lazy counters default for mkfs

[Russell Cattelan]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

Nathan Scott wrote:
> On Thu, 2008-02-28 at 12:09 +1100, Barry Naujok wrote:
>   
>> Lazy superblock counters was released into mainline in 2.6.23-rc1.
>> Some  
>> distros are still running an older kernel (2.6.22 for example) and
>> with  
>>     
>
> (many distros?  RHEL5 and SLES10 wont have such recent kernels yet,
> right?)
>
>   
>> the latest xfsprogs, cannot mount a freshly made filesystem with
>> default  
>> options.
>>
>> This patch make lazy counters default back to off now.
>>     
>
> Looks good, thanks.
>
>   
>> Users who have a more recent kernel can easily enable them with mkfs
>> or  
>> xfs_admin -c1 (in a patch posted out a few days ago which will be in
>> the  
>> same xfsprogs release as this patch).
>>
>> Lazy counters will default to on again in xfsprogs 2.10.0 (when CI
>> support  
>> is released). This should give enough time for distro kernels to catch
>> up.
>>     
>
> Hmm, that still seems pretty soon to me.  I'd have thought you'd at
> least want to wait until most of the distributions (esp. SUSE for you
> guys) have released versions that have kernels sufficiently recent
> that the default mkfs will work.  Otherwise this will be a recurring
> problem.
>   
I don't suppose there is an easy way to query xfs and find out if it can 
support
the lazy SB option?

> cheers.
>
>   


[-- Attachment #2: cattelan.vcf --]
[-- Type: text/x-vcard, Size: 131 bytes --]

begin:vcard
fn:Russell Cattelan
n:Cattelan;Russell
email;internet:cattelan@thebarn.com
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [REVIEW] Don't make lazy counters default for mkfs

[Eric Sandeen]

Russell Cattelan wrote:


>> Hmm, that still seems pretty soon to me.  I'd have thought you'd at
>> least want to wait until most of the distributions (esp. SUSE for you
>> guys) have released versions that have kernels sufficiently recent
>> that the default mkfs will work.  Otherwise this will be a recurring
>> problem.
>>   
> I don't suppose there is an easy way to query xfs and find out if it can 
> support
> the lazy SB option?

I thought about that; xfs *could* stick someting in /proc/fs/xfs with
supported features or somesuch.

But, the kernel you mkfs under isn't necessarily the one you're going to
need to fall back to tomorrow, though...

-Eric

Re: [REVIEW] Don't make lazy counters default for mkfs

[Russell Cattelan]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Eric Sandeen wrote:
> Russell Cattelan wrote:
>
>
>   
>>> Hmm, that still seems pretty soon to me.  I'd have thought you'd at
>>> least want to wait until most of the distributions (esp. SUSE for you
>>> guys) have released versions that have kernels sufficiently recent
>>> that the default mkfs will work.  Otherwise this will be a recurring
>>> problem.
>>>   
>>>       
>> I don't suppose there is an easy way to query xfs and find out if it can 
>> support
>> the lazy SB option?
>>     
>
> I thought about that; xfs *could* stick someting in /proc/fs/xfs with
> supported features or somesuch.
>
> But, the kernel you mkfs under isn't necessarily the one you're going to
> need to fall back to tomorrow, though...
>
>   
True but at least it could make a bit of a intelligent decision.
and maybe a warning for a while about potentially incompatible flags.

> -Eric
>
>   


[-- Attachment #2: cattelan.vcf --]
[-- Type: text/x-vcard, Size: 131 bytes --]

begin:vcard
fn:Russell Cattelan
n:Cattelan;Russell
email;internet:cattelan@thebarn.com
x-mozilla-html:FALSE
version:2.1
end:vcard

Re: [REVIEW] Don't make lazy counters default for mkfs

[Mark Goodwin]

Russell Cattelan wrote:
> Eric Sandeen wrote:
>> Russell Cattelan wrote:
>>
>>
>>
>>>> Hmm, that still seems pretty soon to me.  I'd have thought you'd at
>>>> least want to wait until most of the distributions (esp. SUSE for you
>>>> guys) have released versions that have kernels sufficiently recent
>>>> that the default mkfs will work.  Otherwise this will be a recurring
>>>> problem.
>>>>
>>> I don't suppose there is an easy way to query xfs and find out if it
>>> can support
>>> the lazy SB option?
>>
>> I thought about that; xfs *could* stick someting in /proc/fs/xfs with
>> supported features or somesuch.

how about /proc/fs/xfs/features
.. any format suggestions?

>> But, the kernel you mkfs under isn't necessarily the one you're going to
>> need to fall back to tomorrow, though...

nor the one you just installed but haven't rebooted into yet

> True but at least it could make a bit of a intelligent decision.
> and maybe a warning for a while about potentially incompatible flags.

yes agree

Cheers

-- 

  Mark Goodwin                                  markgw@sgi.com
  Engineering Manager for XFS and PCP    Phone: +61-3-99631937
  SGI Australian Software Group           Cell: +61-4-18969583
-------------------------------------------------------------

Re: [REVIEW] Don't make lazy counters default for mkfs

[Eric Sandeen]

Mark Goodwin wrote:
> 
> Russell Cattelan wrote:
>> Eric Sandeen wrote:
>>> Russell Cattelan wrote:
>>>
>>>
>>>
>>>>> Hmm, that still seems pretty soon to me.  I'd have thought you'd at
>>>>> least want to wait until most of the distributions (esp. SUSE for you
>>>>> guys) have released versions that have kernels sufficiently recent
>>>>> that the default mkfs will work.  Otherwise this will be a recurring
>>>>> problem.
>>>>>
>>>> I don't suppose there is an easy way to query xfs and find out if it
>>>> can support
>>>> the lazy SB option?
>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs with
>>> supported features or somesuch.
> 
> how about /proc/fs/xfs/features
> .. any format suggestions?

maybe just 2 values, with the actual supported features (& features2)
values anded together?  Easy enough to parse in the code.

i.e.

# cat /proc/fs/xfs/features
0xffffffff
0x00000001


?

-Eric

Re: [REVIEW] Don't make lazy counters default for mkfs

[Josef 'Jeff' Sipek]

On Sat, Mar 01, 2008 at 10:47:06AM +1100, Mark Goodwin wrote:
> Russell Cattelan wrote:
>> Eric Sandeen wrote:
>>> Russell Cattelan wrote:
>>>>> Hmm, that still seems pretty soon to me.  I'd have thought you'd at
>>>>> least want to wait until most of the distributions (esp. SUSE for you
>>>>> guys) have released versions that have kernels sufficiently recent
>>>>> that the default mkfs will work.  Otherwise this will be a recurring
>>>>> problem.
>>>>>
>>>> I don't suppose there is an easy way to query xfs and find out if it
>>>> can support
>>>> the lazy SB option?
>>>
>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs with
>>> supported features or somesuch.
>
> how about /proc/fs/xfs/features
> .. any format suggestions?

I'd say strings like:

lazy-count
attr2

Something that'd match the mkfs option strings closely.

This would make iterating over the features supported easy in a shell
script...

cat /proc/fs/xfs/features | while read feat ; do something $feat ; done

I get the feeling that this might be useful even if mkfs doesn't check it.

>>> But, the kernel you mkfs under isn't necessarily the one you're going to
>>> need to fall back to tomorrow, though...
>
> nor the one you just installed but haven't rebooted into yet

Right, if you know what you are doing, you can specify whatever options you
want by hand...this is about the default values.

Another issue is with portable media - I use XFS on external disks, and
until recently I couldn't redo them with lazy-count if I wanted to use it on
my laptop.

Josef 'Jeff' Sipek.

-- 
A CRAY is the only computer that runs an endless loop in just 4 hours...

Re: [REVIEW] Don't make lazy counters default for mkfs

[Eric Sandeen]

Eric Sandeen wrote:

> maybe just 2 values, with the actual supported features (& features2)
> values anded together?  Easy enough to parse in the code.
> 
> i.e.
> 
> # cat /proc/fs/xfs/features
> 0xffffffff
> 0x00000001

hm, but of course mkfs should never be checking for anything in the
first features slot; yesterday's kernels support all those flags but
don't export anything.

wow, this is starting to feel as complex as ext4's flags ;)

-Eric

Re: [REVIEW] Don't make lazy counters default for mkfs

[Andi Kleen]

"Barry Naujok" <bnaujok@sgi.com> writes:
> 
> Lazy counters will default to on again in xfsprogs 2.10.0 (when CI
> support  is released).

CI is what? 

-Andi

Re: [REVIEW] Don't make lazy counters default for mkfs

[Josef 'Jeff' Sipek]

On Sun, Mar 02, 2008 at 11:26:07AM +0100, Andi Kleen wrote:
> "Barry Naujok" <bnaujok@sgi.com> writes:
> > 
> > Lazy counters will default to on again in xfsprogs 2.10.0 (when CI
> > support  is released).
> 
> CI is what? 

Case-insensitivity aka. case-folding.

Josef 'Jeff' Sipek.

-- 
Bad pun of the week: The formula 1 control computer suffered from a race
condition

Re: [REVIEW] Don't make lazy counters default for mkfs

[Nathan Scott]

On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote:
> 
> > I thought about that; xfs *could* stick someting in /proc/fs/xfs
> with
> > supported features or somesuch.
> >
> > But, the kernel you mkfs under isn't necessarily the one you're
> going to
> > need to fall back to tomorrow, though...
> >
> >   
> True but at least it could make a bit of a intelligent decision.
> and maybe a warning for a while about potentially incompatible flags. 

Might also be a good idea to require -f to force a mkfs of a filesystem
which the kernel doesn't support.

Would be good to get blocksize > pagesize into this scheme too btw, and
unfortunately that one isn't a superblock flag) - so this scheme might
need to go beyond those flags, if anyone decides to implement it.

cheers.

-- 
Nathan

Re: [REVIEW] Don't make lazy counters default for mkfs

[Barry Naujok]

On Sat, 01 Mar 2008 11:11:03 +1100, Eric Sandeen <sandeen@sandeen.net>  
wrote:

> Eric Sandeen wrote:
>
>> maybe just 2 values, with the actual supported features (& features2)
>> values anded together?  Easy enough to parse in the code.
>>
>> i.e.
>>
>> # cat /proc/fs/xfs/features
>> 0xffffffff
>> 0x00000001
>
> hm, but of course mkfs should never be checking for anything in the
> first features slot; yesterday's kernels support all those flags but
> don't export anything.

Bzzzzt!

IRIX/ASCII case-insensitive mode (or OLDCI or "V1 CI" as I'm  calling it  
:) )
is in the first features slot - 0x4000

> wow, this is starting to feel as complex as ext4's flags ;)
>
> -Eric
>
>

Re: [REVIEW] Don't make lazy counters default for mkfs

[Timothy Shimmin]

Nathan Scott wrote:
> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote:
>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs
>> with
>>> supported features or somesuch.
>>>
>>> But, the kernel you mkfs under isn't necessarily the one you're
>> going to
>>> need to fall back to tomorrow, though...
>>>
>>>   
>> True but at least it could make a bit of a intelligent decision.
>> and maybe a warning for a while about potentially incompatible flags. 
> 
> Might also be a good idea to require -f to force a mkfs of a filesystem
> which the kernel doesn't support.
> 
   	
974981: mkfs.xfs should warn if it is about to create a fs that cannot be mounted

Ivan was wanting this in December last year. Remember, Mark?
He wanted to know what XFS features the running kernel supported?

I don't think Dave (dgc) and others were not so keen on it IIRC.

(Seems fine to me:)

--Tim

Re: [REVIEW] Don't make lazy counters default for mkfs

[Donald Douwsma]

Nathan Scott wrote:
> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote:
>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs
>> with
>>> supported features or somesuch.
>>>
>>> But, the kernel you mkfs under isn't necessarily the one you're
>> going to
>>> need to fall back to tomorrow, though...
>>>
>>>   
>> True but at least it could make a bit of a intelligent decision.
>> and maybe a warning for a while about potentially incompatible flags. 
> 
> Might also be a good idea to require -f to force a mkfs of a filesystem
> which the kernel doesn't support.

Could work but I dont like the idea of using -f for anything but mkfsing an
existing filesystem. If that becomes habit for people it could lead to disasters.

Don

Re: [REVIEW] Don't make lazy counters default for mkfs

[Nathan Scott]

On Mon, 2008-03-03 at 11:18 +1100, Donald Douwsma wrote:
> 
> 
> Could work but I dont like the idea of using -f for anything but
> mkfsing an
> existing filesystem. If that becomes habit for people it could lead to
> disasters. 

Its already used for more than just overwriting existing filesystems. :)
And it is already habit for some people.  Which leads to disasters, yes.

Its not a perfect system, but there's only so much you can do for people
before they shoot themselves in the foot.

-- 
Nathan

Re: [REVIEW] Don't make lazy counters default for mkfs

[Mark Goodwin]

Timothy Shimmin wrote:
> Nathan Scott wrote:
>> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote:
>>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs
>>> with
>>>> supported features or somesuch.
>>>>
>>>> But, the kernel you mkfs under isn't necessarily the one you're
>>> going to
>>>> need to fall back to tomorrow, though...
>>>>
>>>>   
>>> True but at least it could make a bit of a intelligent decision.
>>> and maybe a warning for a while about potentially incompatible flags. 
>>
>> Might also be a good idea to require -f to force a mkfs of a filesystem
>> which the kernel doesn't support.
>>
>      
> 974981: mkfs.xfs should warn if it is about to create a fs that cannot 
> be mounted
> 
> Ivan was wanting this in December last year. Remember, Mark?
> He wanted to know what XFS features the running kernel supported?

It was worse than that - IIRC, he wanted to know what features are
supported by the XFS kernel module he just installed (this was part
of an Appman upgrade scenario). I thought we rejected that bug ?

> 
> I don't think Dave (dgc) and others were not so keen on it IIRC.

anyone recall the reasons?

Maybe I'm missing something, but if we export all the feature bits,
both new and old, then (a) an old mkfs will continue to ignore them,
and (b) future versions of mkfs will have all the information needed,
but will need t be smart about how that information is used.

Cheers

-- 

  Mark Goodwin                                  markgw@sgi.com
  Engineering Manager for XFS and PCP    Phone: +61-3-99631937
  SGI Australian Software Group           Cell: +61-4-18969583
-------------------------------------------------------------

Re: [REVIEW] Don't make lazy counters default for mkfs

[Josef 'Jeff' Sipek]

On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote:
...
> Maybe I'm missing something, but if we export all the feature bits,
> both new and old, then (a) an old mkfs will continue to ignore them,
> and (b) future versions of mkfs will have all the information needed,
> but will need t be smart about how that information is used.

IMHO:

1) mkfs should make a filesystem, the defaults should be conservative (say
   using features that have been around >1 year)

2) xfs should export supported features to userspace

3) if you want to make sure that the fs you create will be mountable with
   your current kernel, write a small shell script or something along those
   lines that reads the features from some kernel interface, and based on
   those passes the right options to mkfs

4) if you just use mkfs and it creates a fs that's incompatible with your
   current kernel, the mount will fail - as it does today, but perhaps a
   less cryptic error message would be in order

Since installers are just gigantic wrappers around basic commands like mkfs,
#3 gets nicely covered.

Josef 'Jeff' Sipek.

-- 
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
		- George Bernard Shaw

Re: [REVIEW] Don't make lazy counters default for mkfs

[Eric Sandeen]

Josef 'Jeff' Sipek wrote:
> On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote:
> ...
>> Maybe I'm missing something, but if we export all the feature bits,
>> both new and old, then (a) an old mkfs will continue to ignore them,
>> and (b) future versions of mkfs will have all the information needed,
>> but will need t be smart about how that information is used.
> 
> IMHO:
> 
> 1) mkfs should make a filesystem, the defaults should be conservative (say
>    using features that have been around >1 year)

I suppose I have to agree, unfortunately that means most competetive
benchmarks will be using sub-optimal mkfs's, but...

> 2) xfs should export supported features to userspace
> 
> 3) if you want to make sure that the fs you create will be mountable with
>    your current kernel, write a small shell script or something along those
>    lines that reads the features from some kernel interface, and based on
>    those passes the right options to mkfs

> 4) if you just use mkfs and it creates a fs that's incompatible with your
>    current kernel, the mount will fail - as it does today, but perhaps a
>    less cryptic error message would be in order

Ya know, good point.  We already have "running kernel compatibility
checks" built in; it's called "see what happens when you mount it"

It's not like we're running mkfs.ext3 here... ;)  mkfs; mount will tell
you quickly if there's a problem, won't it.  Adding complexity to mkfs
might not make a lot of sense.

And I still am not a huge fan of checking the currently-running kernel;
that's just a point in time, and not necessarily what you're gonna mount
it with.  (heck maybe you're mkfs'ing a san filesystem?)

it's unix, after all.  hand out the hangin' rope... just make the kernel
 explain exactly how & why you've just hung yourself at mount time, in
that case....

-Eric

Re: [REVIEW] Don't make lazy counters default for mkfs

[Josef 'Jeff' Sipek]

On Sun, Mar 02, 2008 at 09:56:50PM -0600, Eric Sandeen wrote:
> Josef 'Jeff' Sipek wrote:
> > On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote:
> > ...
> >> Maybe I'm missing something, but if we export all the feature bits,
> >> both new and old, then (a) an old mkfs will continue to ignore them,
> >> and (b) future versions of mkfs will have all the information needed,
> >> but will need t be smart about how that information is used.
> > 
> > IMHO:
> > 
> > 1) mkfs should make a filesystem, the defaults should be conservative (say
> >    using features that have been around >1 year)
> 
> I suppose I have to agree, unfortunately that means most competetive
> benchmarks will be using sub-optimal mkfs's, but...
 
Benchmarks that use default mkfs options on xfs, but non-default on other
fs?

If you want, have a simple printf in mkfs that tells the user that he's not
using the latest and greatest features (e.g., lazy-count); that should be
enough to make it obvious that there're better options than the default.

> It's not like we're running mkfs.ext3 here... ;)  mkfs; mount will tell
> you quickly if there's a problem, won't it.  Adding complexity to mkfs
> might not make a lot of sense.

Exactly :)

Josef 'Jeff' Sipek.

-- 
I already backed up the [server] once, I can do it again.
		- a sysadmin threatening to do more frequent backups

Re: [REVIEW] Don't make lazy counters default for mkfs

[Eric Sandeen]

Josef 'Jeff' Sipek wrote:
> On Sun, Mar 02, 2008 at 09:56:50PM -0600, Eric Sandeen wrote:
>> Josef 'Jeff' Sipek wrote:
>>> On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote:
>>> ...
>>>> Maybe I'm missing something, but if we export all the feature bits,
>>>> both new and old, then (a) an old mkfs will continue to ignore them,
>>>> and (b) future versions of mkfs will have all the information needed,
>>>> but will need t be smart about how that information is used.
>>> IMHO:
>>>
>>> 1) mkfs should make a filesystem, the defaults should be conservative (say
>>>    using features that have been around >1 year)
>> I suppose I have to agree, unfortunately that means most competetive
>> benchmarks will be using sub-optimal mkfs's, but...
>  
> Benchmarks that use default mkfs options on xfs, but non-default on other
> fs?

most benchmarks I see tune the heck out of "the home team" and leave the
rest ;)

> If you want, have a simple printf in mkfs that tells the user that he's not
> using the latest and greatest features (e.g., lazy-count); that should be
> enough to make it obvious that there're better options than the default.

eh, nobody reads that stuff :)

-Eric

Re: [REVIEW] Don't make lazy counters default for mkfs

[Niv Sardi]

Mark Goodwin <markgw@sgi.com> writes:

> Timothy Shimmin wrote:
>> Nathan Scott wrote:
>>> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote:
>>>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs
>>>> with
>>>>> supported features or somesuch.
>>>>>
>>>>> But, the kernel you mkfs under isn't necessarily the one you're
>>>> going to
>>>>> need to fall back to tomorrow, though...
>>>>>
>>>>>   
>>>> True but at least it could make a bit of a intelligent decision.
>>>> and maybe a warning for a while about potentially incompatible
>>>> flags. 
>>>
>>> Might also be a good idea to require -f to force a mkfs of a filesystem
>>> which the kernel doesn't support.
>>>
>>      974981: mkfs.xfs should warn if it is about to create a fs that
>> cannot be mounted
>>
>> Ivan was wanting this in December last year. Remember, Mark?
>> He wanted to know what XFS features the running kernel supported?
>
> It was worse than that - IIRC, he wanted to know what features are
> supported by the XFS kernel module he just installed (this was part
> of an Appman upgrade scenario). I thought we rejected that bug ?
>
>>
>> I don't think Dave (dgc) and others were not so keen on it IIRC.
>
> anyone recall the reasons?

Yes, we got to the consensus that having mkfs check for kernel stuff is
plain wrong, and there are a load of reasons to that, the most
convincing is that you can have no XFS support in the kernel at mkfs
time (i.e. module, that'll be loaded only on mount). Others reasons go
along the line of:
* You could be mkfsing for another box/kernel.
* We want people to run latest kernels if they run latest xfsprogs =)

Cheers,
-- 
Niv Sardi