maxmustermann
/
minio
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

fix multiple typos in documentation

This commit is contained in:
Harshavardhana 2021-08-04 14:15:41 -07:00
parent 109c8acf4f
commit c13cbc64d1
3 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/bucket/replication/DESIGN.md
View File

@ -37,7 +37,7 @@ Note that synchronous replication, i.e. when remote target is configured with --
Existing object replication works similar to regular replication. Objects qualifying for existing object replication are detected when scanner runs, and will be replicated if existing object replication is enabled and applicable replication rules are satisfied. Because replication depends on the immutability of versions, only pre-existing objects created while versioning was enabled can be replicated. Even if replication rules are disabled and re-enabled later, the objects created during the interim will be synced as the scanner queues them. For saving iops, objects qualifying for
existing object replication are not marked as `PENDING` prior to replication.
If the remote site is fully lost and objects previously replicated need to be re-synced, the `mc replicate resync` command with optional flag of `--older-than` needs to be used to trigger re-syncing of previously replicated objects. This command generates a ResetID which is a unique UUID saved to the remote target config along with the applicable date(defaults to time of initiating the reset). All objects created prior to this date are eligible for re-replication if existing object replication is enabled for the replication rule the object satisifes. At the time of completion of replication, `X-Minio-Replication-Reset-Status` is set in the metadata with the timestamp of replication and ResetID. For saving iops, the objects which are re-replicated are not first set to `PENDING` state.
If the remote site is fully lost and objects previously replicated need to be re-synced, the `mc replicate resync` command with optional flag of `--older-than` needs to be used to trigger re-syncing of previously replicated objects. This command generates a ResetID which is a unique UUID saved to the remote target config along with the applicable date(defaults to time of initiating the reset). All objects created prior to this date are eligible for re-replication if existing object replication is enabled for the replication rule the object satisfies. At the time of completion of replication, `X-Minio-Replication-Reset-Status` is set in the metadata with the timestamp of replication and ResetID. For saving iops, the objects which are re-replicated are not first set to `PENDING` state.
### Internal metadata for replication

2
docs/extensions/s3zip/examples/boto3/main.py
View File

@ -20,6 +20,6 @@ event_system.register_first('before-sign.s3.*', _add_header)
response = s3.list_objects_v2(Bucket="your-bucket", Prefix="path/to/file.zip/")
print(response)
# Downlaod data.csv stored in the zip file
# Download data.csv stored in the zip file
s3.download_file(Bucket='your-bucket', Key='path/to/file.zip/data.csv', Filename='/tmp/data.csv')

2
docs/minio-limits.md
View File

@ -31,7 +31,7 @@ For best deployment experience MinIO recommends operating systems RHEL/CentOS 8.
| Maximum number of multipart uploads returned per list multipart uploads request | 1000 |
| Maximum length for bucket names | 63 |
| Maximum length for object names | 1024 |
| Maximum length for '/' seperated object name segment | 255 |
| Maximum length for '/' separated object name segment | 255 |
### List of Amazon S3 API's not supported on MinIO
We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please open a [GitHub issue](https://github.com/minio/minio/issues).