All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
Cc: Mark Goodwin <markgw@sgi.com>, Timothy Shimmin <tes@sgi.com>,
	nscott@aconex.com, Russell Cattelan <cattelan@thebarn.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: Sun, 02 Mar 2008 22:19:16 -0600	[thread overview]
Message-ID: <47CB7C44.2030508@sandeen.net> (raw)
In-Reply-To: <20080303041409.GC13879@josefsipek.net>

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

  reply	other threads:[~2008-03-03  4:19 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
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 [this message]
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=47CB7C44.2030508@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=bnaujok@sgi.com \
    --cc=cattelan@thebarn.com \
    --cc=jeffpc@josefsipek.net \
    --cc=markgw@sgi.com \
    --cc=nscott@aconex.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.