From: "Josef 'Jeff' Sipek" <jeffpc@josefsipek.net>
To: Mark Goodwin <markgw@sgi.com>
Cc: Russell Cattelan <cattelan@thebarn.com>,
Eric Sandeen <sandeen@sandeen.net>,
nscott@aconex.com, 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: Fri, 29 Feb 2008 19:02:11 -0500 [thread overview]
Message-ID: <20080301000211.GI3520@josefsipek.net> (raw)
In-Reply-To: <47C8997A.9030804@sgi.com>
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...
next prev parent reply other threads:[~2008-03-01 0:02 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 [this message]
2008-03-02 23:34 ` Nathan Scott
2008-03-03 0:16 ` Timothy Shimmin
2008-03-03 0:30 ` Mark Goodwin
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=20080301000211.GI3520@josefsipek.net \
--to=jeffpc@josefsipek.net \
--cc=bnaujok@sgi.com \
--cc=cattelan@thebarn.com \
--cc=markgw@sgi.com \
--cc=nscott@aconex.com \
--cc=sandeen@sandeen.net \
--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