mirror/opencloud
1
0
Fork 0
mirror of https://github.com/opencloud-eu/opencloud.git synced 2026-01-06 04:09:40 -06:00
Code Issues Packages Projects Releases Wiki Activity

Change (ocis,OCIS) to oCIS, unify GitHub branding

Browse Source
This commit is contained in:
Pascal Wengerter
2021-01-28 00:32:47 +00:00
parent 8dd28582cc
commit d7b1ecb3dc
27 changed files with 79 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/extensions/storage/_index.md
View File

@@ -8,7 +8,7 @@ geekdocFilePath: _index.md
geekdocCollapseSection: true
---
This service provides an ocis extension that wraps [reva](https://github.com/cs3org/reva/) and adds an opinionated configuration to it.
This service provides an oCIS extension that wraps [reva](https://github.com/cs3org/reva/) and adds an opinionated configuration to it.
It uses the port range 9140-9179 to preconfigure several services.
@@ -43,4 +43,4 @@ It uses the port range 9140-9179 to preconfigure several services.
| 9165 | storage oc data debug |
| 9166-9177 | reserved for s3, wnd, custom + data providers |
| 9178 | storage public link |
| 9179 | storage public link data |
| 9179 | storage public link data |

4
docs/extensions/storage/storages.md
View File

@@ -13,11 +13,11 @@ geekdocFilePath: storages.md
## Storage providers
To manage the file tree ocis uses storage *storage providers* that are accessing the underlying storage using a *storage driver*. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem ([theoretically](https://danluu.com/deconstruct-files/)) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
To manage the file tree oCIS uses *storage providers* that are accessing the underlying storage using a *storage driver*. The driver can be used to change the implementation of a storage aspect to better reflect the actual underlying storage capabilities. As an example a move operation on a POSIX filesystem ([theoretically](https://danluu.com/deconstruct-files/)) is an atomic operation. When trying to implement a file tree on top of S3 there is no native move operation that can be used. A naive implementation might fall back on a COPY and DELETE. Some S3 implementations provide a COPY operation that uses an existing key as the source, so the file at least does not need to be reuploaded. In the worst case scenario, which is renaming a folder with hundreds of thousands of objects, a reupload for every file has to be made. Instead of hiding this complexity a better choice might be to disable renaming of files or at least folders on S3. There are however implementations of filesystems on top of S3 that store the tree metadata in dedicated objects or use a completely different persistence mechanism like a distributed key value store to implement the file tree aspect of a storage.
{{< hint info >}}
While the *storage provider* is responsible for managing the tree, file up and download is delegated to a dedicated *data provider*. See below.
While the *storage provider* is responsible for managing the tree, file up- and downloads are delegated to a dedicated *data provider*. See below.
{{< /hint >}}
## Storage aspects