From: Mark Goodwin <markgw@sgi.com>
To: Timothy Shimmin <tes@sgi.com>
Cc: nscott@aconex.com, Russell Cattelan <cattelan@thebarn.com>,
Eric Sandeen <sandeen@sandeen.net>,
Barry Naujok <bnaujok@sgi.com>,
"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: [REVIEW] Don't make lazy counters default for mkfs
Date: Mon, 03 Mar 2008 11:30:14 +1100 [thread overview]
Message-ID: <47CB4696.1030304@sgi.com> (raw)
In-Reply-To: <47CB434B.4040005@sgi.com>
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
-------------------------------------------------------------
next prev parent reply other threads:[~2008-03-03 0:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-28 1:09 [REVIEW] Don't make lazy counters default for mkfs Barry Naujok
2008-02-28 2:35 ` Nathan Scott
2008-02-29 21:21 ` Russell Cattelan
2008-02-29 23:11 ` Eric Sandeen
2008-02-29 23:19 ` Russell Cattelan
2008-02-29 23:47 ` Mark Goodwin
2008-02-29 23:56 ` Eric Sandeen
2008-03-01 0:11 ` Eric Sandeen
2008-03-02 23:59 ` Barry Naujok
2008-03-01 0:02 ` Josef 'Jeff' Sipek
2008-03-02 23:34 ` Nathan Scott
2008-03-03 0:16 ` Timothy Shimmin
2008-03-03 0:30 ` Mark Goodwin [this message]
2008-03-03 1:15 ` Josef 'Jeff' Sipek
2008-03-03 3:56 ` Eric Sandeen
2008-03-03 4:14 ` Josef 'Jeff' Sipek
2008-03-03 4:19 ` Eric Sandeen
2008-03-03 4:47 ` Niv Sardi
2008-03-03 0:18 ` Donald Douwsma
2008-03-03 0:24 ` Nathan Scott
2008-03-02 10:26 ` Andi Kleen
2008-03-02 10:41 ` Josef 'Jeff' Sipek
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=47CB4696.1030304@sgi.com \
--to=markgw@sgi.com \
--cc=bnaujok@sgi.com \
--cc=cattelan@thebarn.com \
--cc=nscott@aconex.com \
--cc=sandeen@sandeen.net \
--cc=tes@sgi.com \
--cc=xfs@oss.sgi.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