RepoMirrors/ceph
1
0
Fork 0
mirror of https://github.com/ceph/ceph synced 2024-12-22 19:34:30 +00:00
Code Issues Packages Projects Releases Wiki Activity
7b0168c5dd
ceph/PendingReleaseNotes

38 lines
1.5 KiB
Plaintext
Raw Normal View History

doc: 12.2.0 major release announcements Reordered the RC releases sections back to their respective components, added a ceph-mon section, added links to documentation wherever possible, and a few forgotten RGW announcements. Also cleared up the PendingReleaseNotes upto this point Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
2017-08-24 12:40:33 +00:00
>= 12.2.0
doc: 12.1.1 release notes add major changes Also cleanup PendingReleasenotes to an empty file so that only newer changes are tracked, adding the relevant section back to RC1 where relevant. Moving all the RC1 announcements back to RC2, when we go to 12.2.0 we'll collapse all of these back to the release announcments Signed-off-by: Abhishek Lekshmanan <alekshmanan@suse.com>
2017-08-02 15:41:13 +00:00
---------
mds: support limiting cache by memory This introduces two config parameters: mds_cache_memory_limit: Sets the soft maximum of the cache to the given byte count. (Like mds_cache_size, this doesn't actually limit the maximum size of the cache. It just dictates the steady-state size.) mds_cache_reservation: This replaces mds_health_cache_threshold everywhere except the Beacon heartbeat sent to the mons. The idea here is to specify a reservation of memory (5% by default) for operations and the MDS tries to always maintain that reservation. So, the MDS will recall caps from clients when it begins dipping into its reservation of memory. mds_cache_size still limits the cache by Inode count but is now by-default 0 (i.e. unlimited). The new preferred way of specifying cache limits is by memory size. The default is 1GB. Fixes: http://tracker.ceph.com/issues/20594 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1464976 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
2017-09-11 22:21:52 +00:00
doc: rgw: add a note for resharding in 12.2.1 docs Since we're now enabling dynamic resharding, mention this in release notes Signed-off-by: Abhishek Lekshmanan <abhishek@suse.com>
2017-09-15 21:20:27 +00:00
12.2.1
------
- *RGW*
* dynamic resharding is now enabled by default, RGW will now automatically
reshard the bucket index once the index grows beyond `rgw_max_objs_per_shard`
mds: support limiting cache by memory This introduces two config parameters: mds_cache_memory_limit: Sets the soft maximum of the cache to the given byte count. (Like mds_cache_size, this doesn't actually limit the maximum size of the cache. It just dictates the steady-state size.) mds_cache_reservation: This replaces mds_health_cache_threshold everywhere except the Beacon heartbeat sent to the mons. The idea here is to specify a reservation of memory (5% by default) for operations and the MDS tries to always maintain that reservation. So, the MDS will recall caps from clients when it begins dipping into its reservation of memory. mds_cache_size still limits the cache by Inode count but is now by-default 0 (i.e. unlimited). The new preferred way of specifying cache limits is by memory size. The default is 1GB. Fixes: http://tracker.ceph.com/issues/20594 Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1464976 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
2017-09-11 22:21:52 +00:00
- *CephFS*:
* Limiting MDS cache via a memory limit is now supported using the new
mds_cache_memory_limit config option (1GB by default). A cache reservation
can also be specified using mds_cache_reservation as a percentage of the
limit (5% by default). Limits by inode count are still supported using
mds_cache_size. Setting mds_cache_size to 0 (the default) disables the
inode limit.
mon/OSDMonitor: prevent pg_num from exceeding mon_pg_warn_max_per_osd Check total pg count for the cluster vs osd count and max pgs per osd before allowing pool creation, pg_num change, or pool size change. "in" OSDs are the ones we distribute data too, so this should be the right count to use. (Whether they happen to be up or down at the moment is incidental.) If the user really wants to create the pool, they can change the configurable limit. Signed-off-by: Sage Weil <sage@redhat.com>
2017-09-01 18:45:12 +00:00
* The maximum number of PGs per OSD before the monitor issues a
warning has been reduced from 300 to 200 PGs. 200 is still twice
the generally recommended target of 100 PGs per OSD. This limit can
mon: rename mon_pg_warn_max_per_osd -> mon_max_pg_per_osd Signed-off-by: Sage Weil <sage@redhat.com>
2017-09-14 20:00:31 +00:00
be adjusted via the ``mon_max_pg_per_osd`` option on the
monitors. The older ``mon_pg_warn_max_per_osd`` option has been removed.
mon/OSDMonitor: prevent pg_num from exceeding mon_pg_warn_max_per_osd Check total pg count for the cluster vs osd count and max pgs per osd before allowing pool creation, pg_num change, or pool size change. "in" OSDs are the ones we distribute data too, so this should be the right count to use. (Whether they happen to be up or down at the moment is incidental.) If the user really wants to create the pool, they can change the configurable limit. Signed-off-by: Sage Weil <sage@redhat.com>
2017-09-01 18:45:12 +00:00
* Creating pools or adjusting pg_num will now fail if the change would
make the number of PGs per OSD exceed the configured
mon: rename mon_pg_warn_max_per_osd -> mon_max_pg_per_osd Signed-off-by: Sage Weil <sage@redhat.com>
2017-09-14 20:00:31 +00:00
``mon_max_pg_per_osd`` limit. The option can be adjusted if it
mon/OSDMonitor: prevent pg_num from exceeding mon_pg_warn_max_per_osd Check total pg count for the cluster vs osd count and max pgs per osd before allowing pool creation, pg_num change, or pool size change. "in" OSDs are the ones we distribute data too, so this should be the right count to use. (Whether they happen to be up or down at the moment is incidental.) If the user really wants to create the pool, they can change the configurable limit. Signed-off-by: Sage Weil <sage@redhat.com>
2017-09-01 18:45:12 +00:00
is really necessary to create a pool with more PGs.
PendingReleaseNotes: note about upmap mapping change in luminous release notes Signed-off-by: Sage Weil <sage@redhat.com>
2017-09-19 17:51:13 +00:00
* There was a bug in the PG mapping behavior of the new *upmap*
feature. If you made use of this feature (e.g., via the `ceph osd
pg-upmap-items` command), we recommend that all mappings be removed (via
the `ceph osd rm-pg-upmap-items` command) before upgrading to this
point release.
Reference in New Issue Copy Permalink