Skip to content
This repository has been archived by the owner on Jan 18, 2021. It is now read-only.

Fix doc typos #390

Merged
merged 3 commits into from
Jul 24, 2020
Merged

Fix doc typos #390

merged 3 commits into from
Jul 24, 2020

Conversation

kulmann
Copy link
Contributor

@kulmann kulmann commented Jul 22, 2020

This is just fixing some typos on top of #384 and adding the missing changelog entry.

@kulmann kulmann requested review from butonic and jvillafanez July 22, 2020 11:33
@kulmann kulmann self-assigned this Jul 22, 2020
@kulmann kulmann added the documentation Improvements or additions to documentation label Jul 22, 2020
docs/storages.md Outdated
@@ -13,7 +13,7 @@ geekdocFilePath: storages.md

## Storage providers

To manage the file tree ocis uses reva *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 S3 there is no native move operation that can be used. A naive implementation might fall bak 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, the rename of 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 persistance mechanism like a distributed key value store to implement the file tree aspect of a storage.
To manage the file tree ocis uses reva *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, to rename of 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"In the worst case scenario, the rename of a folder with hundreds of thousands of objects, a reupload for every file has to be made"

Some additional alternatives:

  • "In the worst case scenario, which is the rename of a folder with hundreds of thousands of objects, a reupload for every file has to be made"
  • "In the worst case scenario, a reupload for every file has to be made in order to rename of a folder with hundreds of thousands of objects,"

Copy link
Member

@jvillafanez jvillafanez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Up to you to decide.

@kulmann kulmann merged commit 3c0e90f into master Jul 24, 2020
@delete-merged-branch delete-merged-branch bot deleted the fix-doc-typos branch July 24, 2020 11:36
ownclouders pushed a commit that referenced this pull request Jul 24, 2020
Merge: 40a23cd 79068fe
Author: Benedikt Kulmann <benedikt@kulmann.biz>
Date:   Fri Jul 24 13:36:25 2020 +0200

    Merge pull request #390 from owncloud/fix-doc-typos

    Fix doc typos
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants