Latest News:

Radisys Unveils Engage Clarity to Enhance Phone Conversations for People Experiencing Hearing Loss

Boosting Energy Savings with Multi-vendor Hardware and Software Solutions for Cloud Native O-RAN Deployments

Dense Air: Bridging infrastructure and the cloud; shaping the ecosystem of shared wireless services

Radisys Unveils 5G Advanced Wireless Connectivity Software for Industry 4.0 and Private 5G

Radisys Unveils 5G Advanced Wireless Connectivity Software for Industry 4.0 and Private 5G

Radisys to present at MWC Barcelona Feb 26th- 29th, 2024. Visit our NetART showcase at Stand 2D50

upDisk IPFS FAQ

upDisk IPFS FAQ

This section discusses the doubts and queries faced when using the IPFS and the resolution for them.

  • Can the upDisk start with no rlie and decide later? 
    Yes, the UpSuite does this automatically. The mounting option is provided purely for this convenience.

  • Can the roles be switched? 
    Yes, the role can be switched at run time except for the following cases:
    - There is no communication link between the peer services.
    - The system has entered into the splitbrain condition.

  • Should the standby machine be started first? 
    The UpSuite establishes the link depending on the appropriate condition, so the order is not important. This is an implementation decision and is not mandatory as long as the user can monitor the upSuite activities.

  • Should the directory be a mount point? 
    No, the upDisk does not check the type of the mount point. In fact, the only requirement is that the upDisk expects a directory structure. TMPFS (temp file system) is used for demos, UFS (Unix file system) and VXFS (virtual extendable file system) support the underlying VFS (virtual file system) types (UFS is the currently tested). Administratively, multiple upDisk datasets can be created to cover the directories requiring replication only (that is, to add them together, there is no mechanism for subtracting.)

  • Should the RAID arrays or software mirroring on a UFS file system be used? 
    Yes, any improvements in the performance or reliability done at the block or the disk level are completely unknown to the upDisk. Use of better arrays and mirroring is in fact highly encouraged, as is the use of file system logging (journaling) whenever available for the underlying file systems.

  • Should there be multiple upDisk datasets? 
    Yes, the upDisk can have a mix of active and standby datasets on the same machine. For example, the dataset A is active on the left and standby on the right, and dataset B is active on the right and standby on the left. Active/standby indicates the direction of the data flow and the ability to write the dataset – total number of specified upDisk datasets.

  • Should the ‘/ipfs’ be used for the upDisk dataset? 
    No, the ‘/ipfs’ is used for the demo/eval purposes for the upDisk datasets. Any desired name can be used for the datasets.

  • Should the dataset directory be mounted to hide the contents? 
    Yes, this is the preferred method. For example, let the upDisk mount point be ‘/tmp/a/’ so that all the operations are intercepted by the upDisk. There is no possibility of knowing hidden contents.

  • What is the number displayed at the end of the status output? 
    The number indicates the total number of replay and deferred operations that are queued up on the active machine.

  • How many replay operations (ops) can be recorded? 
    In the ‘replay ops’ mode only operation is stored and not data, so the number of operations is linearly dependent on the amount of memory. Each ‘replay op’ takes minimum number of bytes, so many operations can be stored depending on the kernel memory. In the ‘replay summary’ mode, the operations are summarized per file in the kernel node and requires no additional memory, so the amount of memory required is linear to the number of affected files. In the ‘repair’ mode, a difference engine is used to compare the two halves of the dataset in parallel with the application access. No information is stored in the repair mode. The ‘replay ops’ mode is intended for small transient outages (minutes). The ‘replay summary’ mode is intended for outages lasting to longer magnitude orders. The ‘repair’ mode is intended for re-installation, checking the contents, or when the damage has occurred on the standby dataset (the ‘replay ops’ alone cannot rectify it).

  • Should the amount of replay be controlled? 
    No, A threshold is provided for switching between the ‘replay ops’, the ‘replay summary’, and the ‘repair’ modes.

  • Should the fail over (change the role of the dataset) be done without dropping the link)? 
    No, stopping the link and/or restarting the link is a very quick operation that will be managed by the upSuite.

  • How to determine that there is no replay? 
    The ‘ipfsc -i’ command displays if there is any replay or not. The ‘ipfsc -D’ command can be used to wait until the replay or the normal operations are draining (cannot be performed).

  • Can the dataset be switched back from active to standby or vice-versa? 
    Yes, as long as there is no damage that requires the ‘repair’ mode, the datasets can be switched back and forth indefinitely.

  • Can the dataset be unmounted? 
    Yes, with the new NIDB (Network Information Database) the information required by both the standby and the active datasets is preserved.

  • Can the link be dropped only on the active machine?
    No, the link can be dropped from either side (active and standby machines).

  • Should the standby link be started first? 
    Yes, the accept() function is performed on the standby machine and the connect() function on the active machine. This is managed transparently in the upSuite.

  • Why does the hostname change on the link command? 
    The standby machine’s hostname changes as it is always used for both the active and the standby machines.