DXi Software Architecture

Overview

What's Different Between DXi 1.x Software and DXi 2.x Software?

Dedupd – the dedup daemon is no longer required and must be removed from the system.
BPW means no more 256 MB regular BLOBs. Most BLOBs will be 1 GB or 256 MB for compatible shares. But BLOBs could be of any size smaller than this, too.
dedupd, qbfsd, and spaced have been replaced by bpwd and bpapid. Most, if not all, bfst clients now interface with bpapid.
/snfs/Q doesn't exist anymore. The new path is /snfs/ddup.
/Q is still exported but is a qfs file system, not qbfs.
/Q is no longer directly usable on the machine. Instead you have to use the NFS or CIFS interface directly.
- For example, mount localhost:/Q/shares/foo /mnt/shares/foo
Since QBFS no longer exists, there are no longer any .q_frg subdirectories. Moreover, there is no disk cache. Dedup is performed inline.
The procmon.xml file has been moved from /etc/ha.d to /snfs/common/data/hurricane/conf/procmon.conf

The /Q directory is Not Directly Useable with DXi 2.x Software

You can’t manipulate files within /Q on the DXi command line and expect anything useful to happen. This is because /Q is not a supported interface.
You cannot manipulate files within /snfs/ddup using standard tools (with the single exception of mv).
You can use /opt/DXi/bpw/bin/bwcat to look at file data; we currently have no supported way from the DXi command line to put data into a file, however.

Blockpool Wrapper (BPW) is New with DXi 2.x Software

The BPW component accepts incoming requests via the ddup api. The metadata requests will be handled using the underlying filesystem where possible. Data requests may be for inline deduped data or for non-deduped data, depending on whether the data is destined for a deduped or non-deduped share.

High Level Design

BPW interfaces to the various clients (such as NFS) and produces a data stream and metadata operations stream. The data stream is in the form of a list of pcache pages to either read or write at specific offsets. BPW also manages the operation of opening and closing BLOBs and BFST store contexts at the appropriate times.

Write

A list of pcache pages is passed by reference to the BFST store API, representing a logically contiguous chunk of data, which is stored using the standard BFST internals. There is no copy of data between the BFST API client and server, or between BPW and the BFST client. This process is repeated as more data arrives from the client.

BPW eventually decides to end a BLOB at a certain point,, at which point a BLOB tag is returned by the BFST and then managed by BPW.

Read

A list of empty pcache pages is passed by reference to the BFST retrieve API, representing a logically contiguous chunk of data to retrieve. The pages are filled by the BFST. There is no memory copy, as above. This process is repeated as more data is required by the client.

This is all achieved by having the BFST server map a shared memory region that is shared with the clients.

What's Next?

Data Path >