LU-6698 kernel: kernel update RHEL 6.6 [2.6.32-504.23.4.el6]

[fs/lustre-release.git] / lustre / ChangeLog

diff --git a/lustre/ChangeLog b/lustre/ChangeLog
index 0e7e8cb..a8e3505 100644 (file)
--- a/lustre/ChangeLog
+++ b/lustre/ChangeLog
@@ -4,13 +4,15 @@ TBD Intel Corporation
          for currently supported client and server kernel versions.
        * Server known to build on patched kernels:
          2.6.32-431.29.2.el6 (RHEL6.5)
-         2.6.32-504.12.2.el6 (RHEL6.6)
+         2.6.32-504.23.4.el6 (RHEL6.6)
+         3.10.0-229.4.2.el7  (RHEL7.1)
          3.0.101-0.47.52     (SLES11 SP3)
        * Client known to build on unpatched kernels:
          2.6.32-431.29.2.el6 (RHEL6.5)
-         2.6.32-504.12.2.el6 (RHEL6.6)
-         3.10.0-229.1.2      (RHEL7.1)
+         2.6.32-504.23.4.el6 (RHEL6.6)
+         3.10.0-229.4.2.el7  (RHEL7.1)
          3.0.101-0.47.52     (SLES11 SP3)
+         3.12.39-47          (SLES12)
        * Recommended e2fsprogs version: 1.42.9.wc1 or newer
        * NFS export disabled when stack size < 8192 (32-bit Lustre clients),
          since the NFSv4 export of Lustre filesystem with 4K stack may cause a
@@ -458,7 +460,7 @@ Description: Remove set_info(KEY_UNLINKED) from MDS/OSC
 Severity   : enhancement
 Bugzilla   : 19526
 Description: correctly handle big reply message.
-Details    : send LNet event if reply is bigger then buffer and adjust this buffer
+Details    : send LNet event if reply is bigger than buffer and adjust this buffer
              correctly.
 
 Severity   : normal
@@ -2725,7 +2727,7 @@ Severity   : normal
 Bugzilla   : 19128
 Description: Out or order replies might be lost on replay
 Details    : In ptlrpc_retain_replayable_request if we cannot find retained
-             request with tid smaller then one currently being added, add it
+             request with tid smaller than one currently being added, add it
             to the start, not end of the list.
 
 --------------------------------------------------------------------------------
@@ -3073,11 +3075,11 @@ Details    : decrease the amount of synchronous RPC between clients and servers
 Severity   : enhancement
 Bugzilla   : 4900
 Description: Async OSC create to avoid the blocking unnecessarily.
-Details    : If a OST has no remain object, system will block on the creating
-            when need to create a new object on this OST. Now, ways use
-            pre-created objects when available, instead of blocking on an
-            empty osc while others are not empty.  If we must block, we block
-            for the shortest possible period of time.
+Details    : If an OST has no remaining object, system will block on the
+            creation when it needs to create a new object on this OST. Now,
+            ways use pre-created objects when available, instead of blocking on
+            an empty osc while others are not empty.  If we must block, we
+            block for the shortest possible period of time.
 
 Severity   : major
 Bugzilla   : 11710
@@ -3843,7 +3845,7 @@ Details    : If one node attempts to overwrite an executable in use by
 Severity   : enhancement
 Bugzilla   : 4900
 Description: Async OSC create to avoid the blocking unnecessarily.
-Details    : If a OST has no remain object, system will block on the creating
+Details    : If an OST has no remaining object, system will block on the creating
             when need to create a new object on this OST. Now, ways use
             pre-created objects when available, instead of blocking on an
             empty osc while others are not empty.  If we must block, we block
@@ -4751,7 +4753,7 @@ Frequency  : common
 Bugzilla   : 9489, 3273
 Description: First write from each client to each OST was only 4kB in size,
             to initialize client writeback cache, which caused sub-optimal
-            RPCs and poor layout on disk for the first writen file.
+            RPCs and poor layout on disk for the first written file.
 Details    : Clients now request an initial cache grant at (re)connect time
             and so that they can start streaming writes to the cache right
             away and always do full-sized RPCs if there is enough data.