-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[docs-only] Dev docs about collaborative storage #9317
Conversation
Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes. |
docs/architecture/posixfs.md
Outdated
|
||
Posix FS is a backend component that manages files on the server utilizing a "real" file tree that represents the data with folders and files in the file system as users are used to it. That is the big difference compared to Decomposed FS which is the default storage driver in Infinite Scale. | ||
|
||
This does not mean that Infinte Scale is trading any of it's benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to chaches and search index, and it also features the full spaces concept as before, just to name a few example. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not mean that Infinte Scale is trading any of it's benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to chaches and search index, and it also features the full spaces concept as before, just to name a few example. | |
This does not mean that Infinite Scale is trading any of it's benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to caches and search indexes, and it also features the full spaces concept as before, just to name a few examples. |
docs/architecture/posixfs.md
Outdated
|
||
This does not mean that Infinte Scale is trading any of it's benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to chaches and search index, and it also features the full spaces concept as before, just to name a few example. | ||
|
||
The architecture of Infinite Scale allows to configure different storage drivers for specific storage types and purposes on a space granularity. The Posix FS storage driver is an alternative to the default driver called Decomposed FS. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The architecture of Infinite Scale allows to configure different storage drivers for specific storage types and purposes on a space granularity. The Posix FS storage driver is an alternative to the default driver called Decomposed FS. | |
The architecture of Infinite Scale allows configuring different storage drivers for specific storage types and purposes on a space granularity. The Posix FS storage driver is an alternative to the default driver called Decomposed FS. |
docs/architecture/posixfs.md
Outdated
|
||
The architecture of Infinite Scale allows to configure different storage drivers for specific storage types and purposes on a space granularity. The Posix FS storage driver is an alternative to the default driver called Decomposed FS. | ||
|
||
However, the clearance of the file structure in the underlying file system is not the only benefit of the Posix FS. This new technology allows users to manipulate the data directly in the file system, and any changes to files made aside of Infinite Scale are monitored and directly reflected in Infinite Scale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, the clearance of the file structure in the underlying file system is not the only benefit of the Posix FS. This new technology allows users to manipulate the data directly in the file system, and any changes to files made aside of Infinite Scale are monitored and directly reflected in Infinite Scale. | |
However, the clarity of the file structure in the underlying file system is not the only benefit of the Posix FS. This new technology allows users to manipulate the data directly in the file system, and any changes to files made aside of Infinite Scale are monitored and directly reflected in Infinite Scale. |
Maybe you mean something like "clarity"?
docs/architecture/posixfs.md
Outdated
|
||
However, the clearance of the file structure in the underlying file system is not the only benefit of the Posix FS. This new technology allows users to manipulate the data directly in the file system, and any changes to files made aside of Infinite Scale are monitored and directly reflected in Infinite Scale. | ||
|
||
The first time ever with feature rich open source file synce & share systems, users can either choose to work with their data through the clients of the system, it's API's or even directly in the underlying file system on the server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first time ever with feature rich open source file synce & share systems, users can either choose to work with their data through the clients of the system, it's API's or even directly in the underlying file system on the server. | |
For the first time ever with feature rich open source file sync & share systems, users can either choose to work with their data through the clients of the system, it's API's or even directly in the underlying file system on the server. |
docs/architecture/posixfs.md
Outdated
|
||
### Monitoring | ||
|
||
To get information about changes such as new files added, files edited or removed, Infinte Sale uses a monitoring system to directly watch the file system. This starts with the Linux inotify system and ranges to much more sophisticated services as for example in Spectrum Scale (see [GPFS Specifics](#gpfs-specifics) for more details on GPFS file systems). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To get information about changes such as new files added, files edited or removed, Infinte Sale uses a monitoring system to directly watch the file system. This starts with the Linux inotify system and ranges to much more sophisticated services as for example in Spectrum Scale (see [GPFS Specifics](#gpfs-specifics) for more details on GPFS file systems). | |
To get information about changes such as new files added, files edited or removed, Infinite Scale uses a monitoring system to directly watch the file system. This starts with the Linux inotify system and ranges to much more sophisticated services as, for example, in Spectrum Scale (see [GPFS Specifics](#gpfs-specifics) for more details on GPFS file systems). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's another typo here Infinite Sale
docs/architecture/posixfs.md
Outdated
|
||
Based on the information transmitted by the watching service, Infinite Scale is able to "register" new or changed files into its own caches and internal management structures. This enables Infinite Scale to deliver resource changes through the "traditional" channels such as APIs and clients. | ||
|
||
Since the most important metadata is the file tree structure itself, the "split brain" situation between data and metadata is impossible to cause trouble. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the most important metadata is the file tree structure itself, the "split brain" situation between data and metadata is impossible to cause trouble. | |
Since the most important metadata is the file tree structure itself, it is impossible for the "split brain" situation between data and metadata to cause trouble. |
docs/architecture/posixfs.md
Outdated
|
||
### File Id Resolution | ||
|
||
Infinite Scale uses an Id based approach to work with resources, rather than a file path based mechanism. The reason for that is that Id based lookups can be done way more efficient compared to tree traversals, just to name one reason. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Infinite Scale uses an Id based approach to work with resources, rather than a file path based mechanism. The reason for that is that Id based lookups can be done way more efficient compared to tree traversals, just to name one reason. | |
Infinite Scale uses an Id based approach to work with resources, rather than a file path based mechanism. The reason for that is that Id based lookups can be done way more efficiently compared to tree traversals, just to name one reason. |
docs/architecture/posixfs.md
Outdated
|
||
The tech preview comes with the following limitations: | ||
|
||
1. User Management: Manipulations in the file system have to be done by the same user that runs Infinte Scale |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. User Management: Manipulations in the file system have to be done by the same user that runs Infinte Scale | |
1. User Management: Manipulations in the file system have to be done by the same user that runs Infinite Scale |
docs/architecture/posixfs.md
Outdated
1. There must be storage available to store meta data and blobs, available under a root path | ||
2. When using inotify, the storage must be local on the same machine. Network mounts do not work with Inotify | ||
3. The storage root path must be writeable and executable by the same user Infinite Scale is running under | ||
4. An appropiate version of Infinte Scale is installed, version number 5.0.5 and later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
4. An appropiate version of Infinte Scale is installed, version number 5.0.5 and later | |
4. An appropiate version of Infinite Scale is installed, version number 5.0.5 and later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good 👍 Just some nagging as always...
docs/architecture/posixfs.md
Outdated
|
||
Posix FS is a backend component that manages files on the server utilizing a "real" file tree that represents the data with folders and files in the file system as users are used to it. That is the big difference compared to Decomposed FS which is the default storage driver in Infinite Scale. | ||
|
||
This does not mean that Infinte Scale is trading any of it's benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to chaches and search index, and it also features the full spaces concept as before, just to name a few example. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not mean that Infinte Scale is trading any of it's benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to chaches and search index, and it also features the full spaces concept as before, just to name a few example. | |
This does not mean that Infinte Scale is trading any of its benefits to this new feature: It still implements simplicity by running without a database, it continues to store metadata in the file system and adds them transparently to chaches and search index, and it also features the full spaces concept as before, just to name a few example. |
docs/architecture/posixfs.md
Outdated
|
||
However, the clearance of the file structure in the underlying file system is not the only benefit of the Posix FS. This new technology allows users to manipulate the data directly in the file system, and any changes to files made aside of Infinite Scale are monitored and directly reflected in Infinite Scale. | ||
|
||
The first time ever with feature rich open source file synce & share systems, users can either choose to work with their data through the clients of the system, it's API's or even directly in the underlying file system on the server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first time ever with feature rich open source file synce & share systems, users can either choose to work with their data through the clients of the system, it's API's or even directly in the underlying file system on the server. | |
The first time ever with feature rich open source file synce & share systems, users can either choose to work with their data through the clients of the system, its APIs or even directly in the underlying file system on the server. |
docs/architecture/posixfs.md
Outdated
|
||
The first time ever with feature rich open source file synce & share systems, users can either choose to work with their data through the clients of the system, it's API's or even directly in the underlying file system on the server. | ||
|
||
That is another powerful vector for integration and enables a new spectrum of use cases across all domains. Just imagine how many software can write files, and can now directly make them accessible real time in a convenient, secure and efficient way. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just imagine how many software can write files, and can now directly make them accessible real time in a convenient, secure and efficient way.
This I don't understand. Are you talking about other competitors who can't do this?
docs/architecture/posixfs.md
Outdated
|
||
## Advanced Features | ||
|
||
Depending on the capabilities of the underlying file system, the Infinite Scale PosixFS can benefit from more advanced funcitonality described here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depending on the capabilities of the underlying file system, the Infinite Scale PosixFS can benefit from more advanced funcitonality described here. | |
Depending on the capabilities of the underlying file system, the Infinite Scale PosixFS can benefit from more advanced functionality described here. |
I knew I could find a typo if I only looked hard enough!
docs/architecture/posixfs.md
Outdated
2. When using inotify, the storage must be local on the same machine. Network mounts do not work with Inotify | ||
3. The storage root path must be writeable and executable by the same user Infinite Scale is running under | ||
4. An appropiate version of Infinte Scale is installed, version number 5.0.5 and later | ||
5. Either redis or nats-js-kv cache service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't mention redis
. It is not working properly. We want to use nats-js-kv
as only suggested distributed cache solution.
docs/helpers/env_vars.yaml
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you commit this?
docs/services/app-registry/_index.md
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question: Was this commited intentionally?
docs/architecture/posixfs.md
Outdated
|
||
{{< toc >}} | ||
|
||
Posix FS is the working name for the collaborative storage driver for Infinite Scale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a personal opinion, I am not happy with the name Posix FS
.
This is imho misleading as we also have POSIX for metadata and this will cause confusion.
I know that we have a new service recently added named collaboration
but when thinking about, we could use Collaborative FS
as alternative for Posix FS
to make things more clear and distinctive.
Note that the envvar name should then also be corrected (hopefully I catched them all):
STORAGE_USERS_POSIX_ROOT
--> STORAGE_USERS_COLLABORATIVE_FS_ROOT
STORAGE_USERS_DRIVER
--> collaborative
as value
STORAGE_USERS_POSIX_WATCH_TYPE
--> STORAGE_USERS_COLLABORATIVE_FS_WATCH_TYPE
STORAGE_USERS_POSIX_WATCH_PATH
--> STORAGE_USERS_COLLABORATIVE_FS_WATCH_PATH
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
POSIX is IMHO the correct technical term. It makes the difference between Decomposed vs. POSIX
docs/architecture/posixfs.md
Outdated
|
||
## Introduction | ||
|
||
Posix FS is a backend component that manages files on the server utilizing a "real" file tree that represents the data with folders and files in the file system as users are used to it. That is the big difference compared to Decomposed FS which is the default storage driver in Infinite Scale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking into the dev docs and searching for decomposed
, I only find Decomposed FS on NFS. We should add a new documentation about Decomposed FS, what it is about and link that document here for reference so one can compare. This is especially true as Decomposed FS uses POSIX (eg NFS) for metadata stored via messagepack and this new FS driver uses XATTRs as part of the files stored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify: Decomposed FS is "decomposed".
A POSIX compatible filesystem has some requirements. https://www.quobyte.com/storage-explained/posix-filesystem/
POSIX is not NFS.
docs/architecture/posixfs.md
Outdated
|
||
The architecture of Infinite Scale allows to configure different storage drivers for specific storage types and purposes on a space granularity. The Posix FS storage driver is an alternative to the default driver called Decomposed FS. | ||
|
||
However, the clearance of the file structure in the underlying file system is not the only benefit of the Posix FS. This new technology allows users to manipulate the data directly in the file system, and any changes to files made aside of Infinite Scale are monitored and directly reflected in Infinite Scale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe to add an example usecase to make things clear:
This new technology allows users to manipulate the data directly in the file system like when using a scanner storing the output on a filesystem
.
I know that there are many other usecases, but such an example makes the idea clear right at the beginning without counteracting the Decomposed FS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added a sentence with a real life example (scanner)
docs/architecture/posixfs.md
Outdated
|
||
The Posix FS technology uses a few features of the underlying file system, which are mandatory and directly contributing to the performance of the system. | ||
|
||
While the simplest form of Posix FS runs with default file systems of every modern Linux system, the full power of this unfolds with more capable file systems such as IBM Storage Scale or Ceph. These are recommended as reliable foundations for big installations of Infinite Scale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do "default filesystems" include mounted shared file systems like NFS or SMB ?
If yes, this should be added.
I remember, that NFS needs a minimum version (v4.1 or 4.2?) to support xattrs which was some time ago one important reason to move to messagepack. If a minimum version of a mounted FS is still valid, we should add a note about that. Else one thinks NFSv3 is ok to use. No need to go into a detail, but a note about a min versions would be necessary - also for us...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thanks. It only works with local mounted fs - made that more clear in the text.
docs/architecture/posixfs.md
Outdated
|
||
### Automatic ETag Propagation | ||
|
||
The ETag of a resource can be understood as a content fingerprint of any file- or folder resource in Infinite Scale. It is mainly used by clients to detect changes of resources. The rule is that if the content of a file changed the ETag has to change as well, as well as the ETag of all parent folders up to the root of the space. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ETag of a resource can be understood as a content fingerprint of any file- or folder resource in Infinite Scale. It is mainly used by clients to detect changes of resources. The rule is that if the content of a file changed the ETag has to change as well, as well as the ETag of all parent folders up to the root of the space. | |
The ETag of a resource can be understood as a content fingerprint of any file- or folder resource in Infinite Scale. It is mainly used by clients to detect changes of resources. The rule is, that if the content of a file changed, the ETag has to change as well, as well as the ETag of all parent folders up to the root of the space. |
docs/architecture/posixfs.md
Outdated
|
||
Infinite Scale uses a built in mechanism to maintain the ETag for each resource in the file meta data, and also propagates it automatically. | ||
|
||
In the future a sophisticated underlying file system could provide an attribute that fulfills this requirement and changes whenever content or metadata of a resource changes, and - which is most important - also changes the attribute of the parent resource and the parent of the parent etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the future a sophisticated underlying file system could provide an attribute that fulfills this requirement and changes whenever content or metadata of a resource changes, and - which is most important - also changes the attribute of the parent resource and the parent of the parent etc. | |
In the future, a sophisticated underlying file system could provide an attribute that fulfills this requirement and changes whenever content or metadata of a resource changes, and - which is most important - also changes the attribute of the parent resource and the parent of the parent etc. |
docs/architecture/posixfs.md
Outdated
|
||
Similar to the ETag propagation described before, Infinite Scale also tracks the accumulated tree size in all nodes of the file tree. A change to any file requires a re-calculation of the size attribute in all parent folders. | ||
|
||
In the future Infinite Scale could benefit from file systems with native tree size propagation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the future Infinite Scale could benefit from file systems with native tree size propagation. | |
In the future, Infinite Scale could benefit from file systems with native tree size propagation. |
docs/architecture/posixfs.md
Outdated
|
||
Other systems store quota data in the metadata storage and implement propagation of used quota similar to the tree size propagation. | ||
|
||
### File Id Resolution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure, but should we write File ID Resolution
(ID in capital letters, consequently in all occurrences).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
docs/architecture/posixfs.md
Outdated
|
||
### User Management | ||
|
||
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which uid the manipulation happens is an important question. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which uid the manipulation happens is an important question. | |
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which uid the manipulation happens is important. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
docs/architecture/posixfs.md
Outdated
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which uid the manipulation happens is an important question. | ||
|
||
There are a few possible ways for user management: | ||
1. Changes can either be only accepted by the same user that Infinite Scale is running under, for example the user `ocis`. All manipulations in the filesystem have to be done by, and only by, this user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. Changes can either be only accepted by the same user that Infinite Scale is running under, for example the user `ocis`. All manipulations in the filesystem have to be done by, and only by, this user. | |
1. Changes can either be only accepted by the same user that Infinite Scale is running under, for example the user `ocis`. All manipulations in the filesystem have to be done by, and only by this user. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
docs/architecture/posixfs.md
Outdated
|
||
There are a few possible ways for user management: | ||
1. Changes can either be only accepted by the same user that Infinite Scale is running under, for example the user `ocis`. All manipulations in the filesystem have to be done by, and only by, this user. | ||
2. Group based: All users who should be able to manipulate files have to be in a unix group. The Infinite Scale user has also to be in there. The default umask in the directory used has to allow group writing all over the place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. Group based: All users who should be able to manipulate files have to be in a unix group. The Infinite Scale user has also to be in there. The default umask in the directory used has to allow group writing all over the place. | |
2. Group based: All users who should be able to manipulate files have to be in a unix group. The Infinite Scale user has also to be member of that group. The default umask in the directory used has to allow group writing all over the place. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
docs/architecture/posixfs.md
Outdated
If the underlying file system is able to create versions of single resources (imagine a git based file system) this functionality could directly be used by Infinite Scale. | ||
|
||
In the current state of the PosixFS, versioning is not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the underlying file system is able to create versions of single resources (imagine a git based file system) this functionality could directly be used by Infinite Scale. | |
In the current state of the PosixFS, versioning is not supported. | |
In the current state of the PosixFS, versioning is not supported. | |
If the underlying file system is able to create versions of single resources (imagine a git based file system) this functionality could directly be used by Infinite Scale provided in a later version. |
Switching the order. imho no candy and then currently not possible...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm, I have the same sequence in other locations, so I'd like to stay with it.
docs/architecture/posixfs.md
Outdated
If the underlying file system handles deleted files in a trash bin that allows restoring of previously removed files, this functionality could directly be used by Infinite Scale. | ||
|
||
If not available it will follow the [the Free Desktop Trash specificaton](https://specifications.freedesktop.org/trash-spec/trashspec-latest.html). | ||
|
||
In the current state of the PosixFS, trash bin is not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the underlying file system handles deleted files in a trash bin that allows restoring of previously removed files, this functionality could directly be used by Infinite Scale. | |
If not available it will follow the [the Free Desktop Trash specificaton](https://specifications.freedesktop.org/trash-spec/trashspec-latest.html). | |
In the current state of the PosixFS, trash bin is not supported. | |
In the current state of the PosixFS, trash bin is not supported. | |
Infinite Scale could, if provided by a later version: | |
- If the underlying file system handles deleted files in a trash bin that allows restoring of previously removed files, this functionality could directly be used by Infinite Scale. | |
- If not available it will follow the [Free Desktop Trash specificaton](https://specifications.freedesktop.org/trash-spec/trashspec-latest.html). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here
docs/architecture/posixfs.md
Outdated
|
||
## Limitations | ||
|
||
As of Q2/2024 the PosixFS is in technical preview state which means that it is not officially supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As of Q2/2024 the PosixFS is in technical preview state which means that it is not officially supported. | |
As of Q2/2024 the PosixFS is not officially supported and in technical preview state. |
Naming proposal for this feature:
|
@dragotin pls exclude changes in Note that the files get always updated when using |
|
||
While the simplest form of Joint Access Storage Driver runs with default file systems of every modern Linux system which are directly mounted and thus support inotify, the full power of this unfolds with more capable file systems such as IBM Storage Scale or Ceph. These are recommended as reliable foundations for big installations of Infinite Scale. | ||
|
||
This chapter describes some technical aspects of the storage driver. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This chapter describes some technical aspects of the storage driver. | |
This chapter describes some technical aspects of this storage driver. |
|
||
### File ID Resolution | ||
|
||
Infinite Scale uses an ID based approach to work with resources, rather than a file path based mechanism. The reason for that is that ID based lookups can be done way more efficiently compared to tree traversals, just to name one reason. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Infinite Scale uses an ID based approach to work with resources, rather than a file path based mechanism. The reason for that is that ID based lookups can be done way more efficiently compared to tree traversals, just to name one reason. | |
Infinite Scale uses an ID based approach to work with resources, rather than a file path based mechanism. The reason for that is, that ID based lookups can be done way more efficiently compared to tree traversals, just to name one reason. |
|
||
Infinite Scale uses an ID based approach to work with resources, rather than a file path based mechanism. The reason for that is that ID based lookups can be done way more efficiently compared to tree traversals, just to name one reason. | ||
|
||
The most important component of the ID is a unique file ID that identifies the resource within a space. IDeally the Inode of a file could be used here. However, some file systems re-use inodes which must be avoided. Infinite Scale thus does not use the file Inode, but generates a UUID instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most important component of the ID is a unique file ID that identifies the resource within a space. IDeally the Inode of a file could be used here. However, some file systems re-use inodes which must be avoided. Infinite Scale thus does not use the file Inode, but generates a UUID instead. | |
The most important component of the ID is a unique file ID that identifies the resource within a space. Ideally, the Inode of a file could be used here. However, some file systems re-use inodes which must be avoided. Infinite Scale thus does not use the file Inode, but generates a UUID instead. |
|
||
### User Management | ||
|
||
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which uid the manipulation happens is important. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which uid the manipulation happens is important. | |
With the requirement that data can be manipulated either through the filesystem or the Infinite Scale system, the question under which UID the manipulation happens is important. |
|
||
One for all, it seems reasonable to use LDAP to manage users which is the base for the Infinite Scale IDP as well as the system login system via PAM. | ||
|
||
### GID based space access |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
### GID based space access | |
### GID Based Space Access |
1. There must be storage available to store meta data and blobs, available under a root path | ||
1. When using inotify, the storage must be local on the same machine. Network mounts do not work with inotify. `inotifywait` needs to be installed. | ||
1. The storage root path must be writeable and executable by the same user Infinite Scale is running under | ||
1. An appropiate version of Infinite Scale is installed, version number 5.0.5 and later | ||
1. Nats-js-kv as cache service |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. There must be storage available to store meta data and blobs, available under a root path | |
1. When using inotify, the storage must be local on the same machine. Network mounts do not work with inotify. `inotifywait` needs to be installed. | |
1. The storage root path must be writeable and executable by the same user Infinite Scale is running under | |
1. An appropiate version of Infinite Scale is installed, version number 5.0.5 and later | |
1. Nats-js-kv as cache service | |
1. There must be storage available to store meta data and blobs, available under a root path. | |
2. When using inotify, the storage must be local on the same machine. Network mounts do not work with inotify. `inotifywait` needs to be installed. | |
3. The storage root path must be writeable and executable by the same user Infinite Scale is running under. | |
4. An appropiate version of Infinite Scale is installed, version number 5.0.5 and later. | |
5. `nats-js-kv` as cache service. |
export STORAGE_USERS_DRIVER="posix" | ||
export STORAGE_USERS_POSIX_ROOT="/home/kf/tmp/posix-storage" | ||
export STORAGE_USERS_POSIX_WATCH_TYPE="inotifywait" | ||
export STORAGE_USERS_ID_CACHE_STORE="nats-js-kv" | ||
export STORAGE_USERS_ID_CACHE_STORE_NODES="localhost:9233" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would'nt it be good, to be inline with the name of the driver to have all envvars respectively key-values use the driver name? Like STORAGE_USERS_POSIX_ROOT
--> STORAGE_USERS_JASD_ROOT
This would directly match its purpose and would match the name when documenting. Readers immediately have an identification. Joint Access Storage Driver
and POSIX
do not match when reading...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree. That requires code changes, and once these are done, we will bring the changes to this doc in the same PR.
@dragotin as discussed, I have updated doc relevant files that get possibly changed when running When this one is merged, do the following:
|
Some additional cleanups
Co-authored-by: Phil Davis <phil@jankaritech.com>
@dragotin there is still an open suggestion ( |
|
This documentation should explain technical background, design options and opportunities and show how to set up at this stage.
Later, the setup section might be moved to other area of doc.
@aduffeck @mmattel @hodyroff