A system and method are presented that utilize separate append-only arrays to track metadata and real data for a file. All modifications to the file result in metadata records being appended to the end of the metadata array. Write modification commands cause real data to be appended to the file data array. The location of real data on the file data array is identified by a record in the metadata array. Modification commands can be grouped into sets, which complete as a set. Modification sets can rely upon the completeness of prior sets. Read-like commands cause the creation of a virtual array based upon the records of the metadata array. The created virtual array has the same size as the actual file but does not contain the real data for the file. Rather, the virtual file array maps to the actual data stored in the file data array.

Examples of systems described herein include a file server virtual machine of a virtualized file server configured to manage storage of a plurality of storage items. The file server virtual machine including a file system configured to receive an access request directed to a storage item of the plurality of storage items and associated with a user. The file system is further configured to retrieve an access control list having permissions information associated with the storage item, and to cache a permissions profile for the user including all permissions pertaining to the user for the storage item. The file system is further configured to determine whether the access request is permissible based on the cached permissions profile.

Virtual tape emulation software on a Virtual Tape Emulator (VTE) assigns file systems labels based on the tape library name, the logical name of the storage array (from the VTE perspective), and the logical unit number (LUN) of the device on the VTE on which the file system is created. To prevent name conflicts within the VTE Operating System (VTEOS), a UDEV label translation process in the VTEOS creates a new label for the virtual tape file system that will be used by the VTEOS to identify the virtual tape file system. The label is created by concatenating the tape library ID, and the storage system identifier and the device identifier derived from the device World Wide Name (WWN). Since the label is unique within the VTE, UDEV label translation enables the VTEOS to differentiate between multiple replicated copies of the same virtual tape file system.

Virtual tape emulation software on a Virtual Tape Emulator (VTE) assigns file systems labels based on the tape library name, the logical name of the storage array (from the VTE perspective), and the logical unit number (LUN) of the device on the VTE on which the file system is created. To prevent name conflicts within the VTE Operating System (VTEOS), a UDEV label translation process in the VTEOS creates a new label for the virtual tape file system that will be used by the VTEOS to identify the virtual tape file system. The label is created by concatenating the tape library ID, and the storage system identifier and the device identifier derived from the device World Wide Name (WWN). Since the label is unique within the VTE, UDEV label translation enables the VTEOS to differentiate between multiple replicated copies of the same virtual tape file system.

Some implementations of the disclosure are directed to a method, comprising: retrieving, using a device associated with an entity, a document from a system of record; uploading the document for storage in an off-chain system accessible by entities having access to a distributed ledger of a distributed ledger network, the entities comprising the entity; hashing, using the device, one or more fields contained in the document to generate a hash representing a unique reference to the document; generating, using the device, a message comprising a plurality of fields contained in the document and the hash; digitally signing, by the device, using a private key associated with the entity, the message to endorse the hash and the fields contained in the document; and after digitally signing the message, transmitting, by the device, the message to the distributed ledger network to store the hash and the fields in the distributed ledger.

Examples described herein are generally directed towards file server access controls, and more specifically towards a mechanism to create consistent access control lists for local users across different file servers in a distributed file server environment. In operation, a local user system SID (e.g., external SID) may be generated for a first user of a first file server. A global ID based on attributes associated with the user of the first file server may also be generated. The global ID for the user may be stored in metadata associated with an access control list (ACL) for a file accessible through the first file server. Data, including the file may be migrated to a second file server. Based on receiving an access request at the second file server associated with the user based on the external ID, the external ID for the user may be translated into the global ID, and used to determine access to the file.

Examples described herein are generally directed towards file server access controls, and more specifically towards a mechanism to create consistent access control lists for local users across different file servers in a distributed file server environment. In operation, a local user system SID (e.g., external SID) may be generated for a first user of a first file server. A global ID based on attributes associated with the user of the first file server may also be generated. The global ID for the user may be stored in metadata associated with an access control list (ACL) for a file accessible through the first file server. Data, including the file may be migrated to a second file server. Based on receiving an access request at the second file server associated with the user based on the external ID, the external ID for the user may be translated into the global ID, and used to determine access to the file.

Generating a storage interface includes receiving a request for documents, detecting an accounting workflow type corresponding to request, and identifying a document organizational structure matching the accounting workflow type. Further, a virtual storage interface is built using an index on the documents and according to the document organizational structure, and presented.

The technology described herein efficiently determines whether a real inode is shared among views, or owned. In-memory data structures include a view snapshot generation counter that is increased as a snapshot that generates a view is created, and an inode total weight. An in-memory virtual inode cache dataset for a filesystem object associated with the view is instantiated with the value of snapshot generation counter, sharing-related data based on the inode mapping file entry for the object, and an inode access weight. To determine whether the inode is shared (and needs to be split), such as on a write to the object, the in-memory data is evaluated. The real inode is shared if the generation counters are unequal, if the sharing-related data indicates sharing at an intermediate indirect block level, or indicates sharing at the inode level and the inode access weight is less than the inode total weight.

The technology described herein efficiently determines whether a real inode is shared among views, or owned. In-memory data structures include a view snapshot generation counter that is increased as a snapshot that generates a view is created, and an inode total weight. An in-memory virtual inode cache dataset for a filesystem object associated with the view is instantiated with the value of snapshot generation counter, sharing-related data based on the inode mapping file entry for the object, and an inode access weight. To determine whether the inode is shared (and needs to be split), such as on a write to the object, the in-memory data is evaluated. The real inode is shared if the generation counters are unequal, if the sharing-related data indicates sharing at an intermediate indirect block level, or indicates sharing at the inode level and the inode access weight is less than the inode total weight.