On Sat, Jan 09, 2016 at 10:01:51PM +0100, Andrea Gelmini wrote: > Reviewed-by: Darrick J. Wong darrick.wong@xxxxxxxxxx That ought to be: Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> (Note the angle brackets.) Can we get a 'Signed-off-by' tag with your email address in it? The tag is useful for us to keep track of who's contributing what, and certifies that each contributor knows what they're getting into. :) See section 11 in: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches The actual documentation fixes still look fine to me. --D > > --- > admin/XFS_Performance_Tuning/filesystem_tunables.asciidoc | 8 ++++---- > admin/XFS_Performance_Tuning/xfs_performance_tuning.asciidoc | 4 ++-- > design/XFS_Filesystem_Structure/magic.asciidoc | 2 +- > design/xfs-self-describing-metadata.asciidoc | 2 +- > design/xfs-smr-structure.asciidoc | 8 ++++---- > 5 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/admin/XFS_Performance_Tuning/filesystem_tunables.asciidoc b/admin/XFS_Performance_Tuning/filesystem_tunables.asciidoc > index c12981b..30f39bf 100644 > --- a/admin/XFS_Performance_Tuning/filesystem_tunables.asciidoc > +++ b/admin/XFS_Performance_Tuning/filesystem_tunables.asciidoc > @@ -35,7 +35,7 @@ units as used on the +mkfs.xfs+ command line to configure these parameters. > The performance examples given in this section are highly dependent on storage, > CPU and RAM configuration. They are intended as guidelines to illustrate > behavioural differences, not the exact performance any configuration will > -acheive. > +achieve. > ===== > > === Directory block size > @@ -238,7 +238,7 @@ available for storing attributes. > When attributes are stored in the literal area of the inode, both attribute > names and attribute values are limited to a maximum size of 254 bytes. If either > name or value exceeds 254 bytes in length, or the total space used by the > -atributes exceeds the size of the literal area, the entire set of attributes > +attributes exceeds the size of the literal area, the entire set of attributes > stored on the inode are pushed to a separate attribute block instead of being > stored inline. > > @@ -280,7 +280,7 @@ Therefore, the size of the log determines the concurrency of metadata > modification operations the filesystem can sustain, as well as how much and how > frequently metadata writeback occurs. A smaller log forces data > write-back more frequently than a larger log, but can result in lower > -synchronisation overhead as there will be fewer changes aggreagted in memory > +synchronisation overhead as there will be fewer changes aggregated in memory > between synchronisation triggers. Memory pressure also generates synchronisatin > triggers, so large logs may not benefit systems with limited memory. > > @@ -364,7 +364,7 @@ between 32KB and 256KB. It can be configured by use of the +logbsize+ mount > option. > > The number of log buffers can also be configured to between 2 and 8. The default > -is 8 log buffersi and can be configured by the use of the +logbufs+ mount > +is 8 log buffers can be configured by the use of the +logbufs+ mount > option. It is rare that this needs to be configured, and it should only be > considered if there is limited memory and lots of XFS filesystems such that the > memory allocated to the log buffers would consume a significant amount of > diff --git a/admin/XFS_Performance_Tuning/xfs_performance_tuning.asciidoc b/admin/XFS_Performance_Tuning/xfs_performance_tuning.asciidoc > index 0310bbd..b249e35 100644 > --- a/admin/XFS_Performance_Tuning/xfs_performance_tuning.asciidoc > +++ b/admin/XFS_Performance_Tuning/xfs_performance_tuning.asciidoc > @@ -42,8 +42,8 @@ xref:Knowledge[Knowledge Section]. > > The xref:Process[Process section] will cover the typical processes used to > optimise a filesystem for a given workload. If the workload measurements are not > -accurate or reproducable, then no conclusions can be drawn as to whether a > -configuration changes an improvemnt or not. Hence without a robust testing > +accurate or reproducible, then no conclusions can be drawn as to whether a > +configuration changes an improvement or not. Hence without a robust testing > process, no amount of knowledge or observation will result in a well optimised > filesystem configuration. > > diff --git a/design/XFS_Filesystem_Structure/magic.asciidoc b/design/XFS_Filesystem_Structure/magic.asciidoc > index 301cfa0..35d9c2b 100644 > --- a/design/XFS_Filesystem_Structure/magic.asciidoc > +++ b/design/XFS_Filesystem_Structure/magic.asciidoc > @@ -82,5 +82,5 @@ XFS can create really big filesystems! > | Max Dir Size | 32GiB | 32GiB | 32GiB > |===== > > -Linux doesn't suppport files or devices larger than 8EiB, so the block > +Linux doesn't support files or devices larger than 8EiB, so the block > limitations are largely ignorable. > diff --git a/design/xfs-self-describing-metadata.asciidoc b/design/xfs-self-describing-metadata.asciidoc > index b7dc3ff..d108f7a 100644 > --- a/design/xfs-self-describing-metadata.asciidoc > +++ b/design/xfs-self-describing-metadata.asciidoc > @@ -5,7 +5,7 @@ v1.0, Feb 2014: Initial conversion to asciidoc > == Introduction > > The largest scalability problem facing XFS is not one of algorithmic > -scalability, but of verification of the filesystem structure. Scalabilty of the > +scalability, but of verification of the filesystem structure. Scalability of the > structures and indexes on disk and the algorithms for iterating them are > adequate for supporting PB scale filesystems with billions of inodes, however it > is this very scalability that causes the verification problem. > diff --git a/design/xfs-smr-structure.asciidoc b/design/xfs-smr-structure.asciidoc > index dd959ab..3e6c4ec 100644 > --- a/design/xfs-smr-structure.asciidoc > +++ b/design/xfs-smr-structure.asciidoc > @@ -142,7 +142,7 @@ Hence we don't actually need any major new data moving functionality in the > kernel to enable this, except maybe an event channel for the kernel to tell > xfs_fsr it needs to do some cleaning work. > > -If we arrange zones into zoen groups, we also have a method for keeping new > +If we arrange zones into zone groups, we also have a method for keeping new > allocations out of regions we are re-organising. That is, we need to be able to > mark zone groups as "read only" so the kernel will not attempt to allocate from > them while the cleaner is running and re-organising the data within the zones in > @@ -173,7 +173,7 @@ it will need ot be packaged by distros. > > If mkfs cannot find ensough random write space for the amount of metadata we > need to track all the space in the sequential write zones and a decent amount of > -internal fielsystem metadata (inodes, etc) then it will need to fail. Drive > +internal filesystem metadata (inodes, etc) then it will need to fail. Drive > vendors are going to need to provide sufficient space in these regions for us > to be able to make use of it, otherwise we'll simply not be able to do what we > need to do. > @@ -193,7 +193,7 @@ bitmaps for verifying used space should already be there. > THere be dragons waiting for us if we don't have random write zones for > metadata. If that happens, we cannot repair metadata in place and we will have > to redesign xfs_repair from the ground up to support such functionality. That's > -jus tnot going to happen, so we'll need drives with a significant amount of > +just not going to happen, so we'll need drives with a significant amount of > random write space for all our metadata...... > > == Quantification of Random Write Zone Capacity > @@ -316,7 +316,7 @@ spiral. > I suspect the best we will be able to do with fallocate based preallocation is > to mark the region as delayed allocation. > > -=== Allocation Alignemnt > +=== Allocation Alignment > > With zone based write pointers, we lose all capability of write alignment to the > underlying storage - our only choice to write is the current set of write > -- > 2.7.0 > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
