概述
對象存儲服務中，有整體上傳和分段上傳，當應用對象大小小于分塊大小時則使用者上傳的對象隻對應一個RADOS對象，該對象以應用對象名命名，應用對象中繼資料也儲存在該 rados對象的擴充屬性中。
當應用對象大于分塊上傳時，如下圖：
應用對象被分解成一個大小等于分塊大小的首對象，多個大小等于條帶大小的中間對象，和一個大小小于等于條帶大小的尾對象。首對象以應用對象名稱命名，在 RGW 中将該對象稱為head_obj，該對象的資料部分儲存了應用對象前 rgw_max_chunk_size 位元組的資料，擴充屬性部分儲存了應用對象的中繼資料資訊和manifest資訊。中間對象和尾對象儲存應用對象剩餘的資料，對象名稱為“shadow_” + “.” + “32bit 随機字元串” + “_” + “條帶編号，其中編号從1開始。
如果業務應用資料本身單個對象比較大，而不希望在對象存儲中被分成太多的rados對象，這時候就需要修改rgw_max_chunk_size，以及strip_size（分段上傳中用到的參數），分段上傳這裡不詳述，更多關于rgw相關内容在附加連結中。
問題描述
當在14版本中加入以下參數後，發現對象存儲無法正常寫入。
rgw_obj_stripe_size = "33554432"
rgw_max_chunk_size = "33554432"
而使用高版本cloudberry/s3browser時可以正常上傳檔案，但是觀察其對象結構，均為采用10M/8M的分段上傳，而配置的32M并沒有實際生效。
而後換成另一套較低版本（12）版本ceph叢集後，修改參數則生效，既可以上傳，也确實是以32M進行分段和分片。
如果相同參數低版本生效而高版本不生效，應該是這塊的源碼做了一些調整，後對源碼進行對比發現。12版本中rgw 上傳采用的是同步，而14版本中是異步機制，代碼片段：
問題解決
後調整ceph配置，重新開機對象存儲服務，可以恢複正常讀寫，且配置生效。而之前使用cloudberry和s3browser上傳時，因為參數無效，采用了自己的預設值進行的分段上傳，需要注意的是，而當配置生效重新開機對象網關服務時，這些分段上傳的對象将不可用。
rgw_put_obj_min_window_size = "33554432"
rgw_obj_stripe_size = "33554432"
rgw_max_chunk_size = "33554432"
其他
RGW相關整理