docs: Move developer docs from top-level to its own directory. (#1642)

This commit is contained in:
Harshavardhana 2016-05-14 02:47:16 -07:00
parent 025054fb36
commit 74c23a3544
7 changed files with 50 additions and 24 deletions

View file

@ -1,10 +0,0 @@
## Multipart backend format
When multipart upload is used for objects, below meta-data/staging files are created
- New multipart upload call creates file ```EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.uploadid```
- Put object part call creates file ```EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.PART_NUMBER.MD5SUM_STRING```
- Abort multipart call removes all files matching ```EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.*```
- Complete multipart call does
1. Create a staging file ```EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete.TEMP_NAME``` then rename to ```EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete```
2. Rename staging file ```EXPORT_DIR/.minio/BUCKET/PATH/TO/OBJECT/UPLOAD_ID.complete``` to ```EXPORT_DIR/BUCKET/PATH/TO/OBJECT```

33
docs/backend-multipart.md Normal file
View file

@ -0,0 +1,33 @@
## Multipart
Each incoming part is uploaded in the following format.
Placeholder uploads.json to indicate a leaf.
```EXPORT_DIR/.minio/multipart/BUCKET/PATH/TO/OBJECT/uploads.json```
Incomplete file
```EXPORT_DIR/.minio/multipart/BUCKET/PATH/TO/OBJECT/UPLOADID/00000.incomplete```
Actual parts
```EXPORT_DIR/.minio/multipart/BUCKET/PATH/TO/OBJECT/UPLOADID/PART_NUMBER.MD5SUM_STRING```
## FS Format.
Each of these parts are concatenated back to a single contigous file.
```EXPORT_DIR/BUCKET/PATH/TO/OBJECT```
## XL Format.
Each of these parts are kept as is in the following format.
Special json file indicate the metata multipart information, essentially list of parts etc.
```EXPORT_DIR/BUCKET/PATH/TO/OBJECT/00000.minio.multipart```
All the parts that were uploaded.
```EXPORT_DIR/BUCKET/PATH/TO/OBJECT/PART_NUMBER.minio.multipart```

View file

@ -4,7 +4,6 @@
- `log.Errorf`
- `log.Warnf`
- `log.Infof`
- `log.Debugf`
Logging is enabled across the codebase. There are three types of logging supported.
@ -12,19 +11,20 @@ Logging is enabled across the codebase. There are three types of logging support
- file
- syslog
Sample logger section from `~/.minio/config.json`
```
"console": {
"enable": true,
"level": "debug"
"level": "error"
},
"file": {
"enable": false,
"fileName": "",
"level": "error"
"level": "trace"
},
"syslog": {
"enable": false,
"address": "",
"level": "debug"
"level": "info"
}
```

View file

@ -19,19 +19,22 @@ minio server <testdir>
JSON RPC namespace is `Web`.
#### Auth Operations
#### Server operations.
* ServerInfo - fetches current server information, includes memory statistics, minio binary
version, golang runtime version and more.
#### Auth operations
* Login - waits for 'username, password' and on success replies a new Json Web Token (JWT).
* ResetToken - resets token, requires password and token.
* Logout - currently a dummy operation.
* SetAuth - change access credentials with new 'username, password'.
* GetAuth - fetch the current auth from the server.
#### Bucket/Object Operations.
#### Bucket/Object operations.
* ListBuckets - lists buckets, requires a valid token.
* ListObjects - lists objects, requires a valid token.
* MakeBucket - make a new bucket, requires a valid token.
* GetObjectURL - generates a URL for download access, requires a valid token.
(generated URL is valid for 1hr)
* PutObjectURL - generates a URL for upload access, requies a valid token.
(generated URL is valid for 1hr)
* RemoveObject - removes an object from a bucket, requires a valid token.
* Upload - uploads a new object from the browser, requires a valid token.
* Download - downloads an object from a bucket, requires a valid token.

View file

@ -1,7 +1,7 @@
### file.json
``file.json`` is a special file captured and written by XL storage API layer
to interpret, manage and extract erasured data to multiple disks.
to interpret, manage and extract erasured data from multiple disks.
```json
{