Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3]

Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3]

[Niv Sardi]

On Mon, Mar 10, 2008 at 5:07 PM, David Chinner <dgc@sgi.com> wrote:
> On Fri, Mar 07, 2008 at 03:39:05PM +1100, Niv Sardi wrote:
>  > Incorporated Eric's changes, last call does it look good to everyone
>
>  > @@ -387,17 +399,13 @@ With some combinations of filesystem block size, inode size,
>  >  and directory block size, the minimum log size is larger than 512 blocks.
>  >  .TP
>  >  .BI version= value
>  > -This specifies the version of the log. The
>  > -.I value
>  > -is either 1 or 2. Specifying
>  > -.B version=2
>  > -enables the
>  > -.B sunit
>  > -suboption, and allows the logbsize to be increased beyond 32K.
>  > -Version 2 logs are automatically selected if a log stripe unit
>  > -is specified.  See
>  > -.BR sunit " and " su
>  > -suboptions, below.
>  > +This specifies the version of the log. The current default is 2,
>  > +which allows for larger log buffer sizes, as well as supporting
>  > +stripe-aligned log writes (see the sunit and su options, below).
>  > +.IP
>  > +The previous version 1, which is limited to 32k log buffers and does
>  > +not support stripe-aligned writes, is kept for backwards compatibility
>  > +with very old 2.4 kernels.

>  I don't like this change. You're removing specific references to the
>  commands needed to set sunit, or how to set the version number, and what
>  the default behaviour on stripe aligned filesystems are.

Right that should be added back.

>  Secondly, version one logs are not being kept around for backwards
>  compatibility reasons. It's a valid, supported configuration, and in
>  some cases performs better than version 2 logs....

Can you be more specific ? the man page should document when this is
better supported and I believe you're the one that has the best
knowledge about that.

>  Realistically, I see no need for changing this text except to add that
>  the default is version 2.

The change was motivated by Eric's comments on OSS that it is not
clear why one should pick log v1 or v2, and I believe he is right.

Cheers,
--
Niv Sardi

Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3]

[David Chinner]

On Mon, Mar 10, 2008 at 05:15:04PM +1100, Niv Sardi wrote:
> On Mon, Mar 10, 2008 at 5:07 PM, David Chinner <dgc@sgi.com> wrote:
> >  Secondly, version one logs are not being kept around for backwards
> >  compatibility reasons. It's a valid, supported configuration, and in
> >  some cases performs better than version 2 logs....
> 
> Can you be more specific ?

More specific about which comment?

Re: performance - specSFS.

IIRC, anything that is effectively a synchronous transaction workload
tends to perform slightly better with v1 logs than v2 logs. It's
in the order of a few percent, but some ppl kill for that ;)

> the man page should document when this is
> better supported and I believe you're the one that has the best
> knowledge about that.
> 
> >  Realistically, I see no need for changing this text except to add that
> >  the default is version 2.
> 
> The change was motivated by Eric's comments on OSS that it is not
> clear why one should pick log v1 or v2, and I believe he is right.

If you don't understand - use the default. In most cases v2 logs are the
right thing to use and no amount of text in the man page is going to be
able to explain the corner cases where you'd want to use v1 logs....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group

Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3]

[Eric Sandeen]

David Chinner wrote:

>> The change was motivated by Eric's comments on OSS that it is not
>> clear why one should pick log v1 or v2, and I believe he is right.
> 
> If you don't understand - use the default. In most cases v2 logs are the
> right thing to use and no amount of text in the man page is going to be
> able to explain the corner cases where you'd want to use v1 logs....

I think the only problem, Dave, is that there are maybe 2 people on the
face of this earth who DO understand ;)  (and I don't count myself among
them).

Just saying that v1 logs are still there for corner cases & specialized
workloads which may perform better is probably fine, don't you think?
That way those people who kill for such things can test both flavors.
Without that, people won't know if v1 is broken, deprecated, dangerous,
or what.

If you say nothing at all about the differences, then don't even bother
to document the log version option at all, IMHO.

-Eric