You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have to think about how to assign "persistent" inode numbers to bucket objects and also to their "virtual directories" as that is what NFS needs to identify objects.
One possible implementation would be to simply not make inodes persistent, but just cache them in memory. This would be ok for uses that only do reads and creates, but even then this could be painful. All clients have to reset their local inode caches after a restart.
A much better implementation would be to allow a global configuration, that when enabled, will maintain a inode number on the bucket_object table based on a sequence through Blazebit/blaze-persistence#365
For directories, we would need a separate table where inodes are managed.
The text was updated successfully, but these errors were encountered:
Use https://github.com/dCache/nfs4j for implementing access to buckets through NFS mounts.
We have to think about how to assign "persistent" inode numbers to bucket objects and also to their "virtual directories" as that is what NFS needs to identify objects.
One possible implementation would be to simply not make inodes persistent, but just cache them in memory. This would be ok for uses that only do reads and creates, but even then this could be painful. All clients have to reset their local inode caches after a restart.
A much better implementation would be to allow a global configuration, that when enabled, will maintain a inode number on the bucket_object table based on a sequence through Blazebit/blaze-persistence#365
For directories, we would need a separate table where inodes are managed.
The text was updated successfully, but these errors were encountered: