ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 21 lines · David Chinner
Quoted 20 lines · Niv Sardi
Incorporated Eric's changes, last call does it look good to everyone
(quoted diff) +3
-11@@ -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).
Quoted 8 lines
Review With some combinations of filesystem block size, inode size, · line 408
Quoted 4 lines
(quoted diff) +4
-0+.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.
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 6 lines · Niv Sardi
Quoted 3 lines · David Chinner
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 ;)
Quoted 9 lines
the man page should document when this is
better supported and I believe you're the one that has the best knowledge about that.Quoted 2 lines
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.
Signature · 3 lines
Dave Chinner Principal Engineer SGI Australian Software Group
Quoted 6 lines · David Chinner
Quoted 2 lines
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