PEARL: Plausibly Deniable Flash Translation Layer using WOM coding

The address translation in DFTL is related to three data structures: the page-level mapping table, the Global Translation Directory (GTD) and the Cached Mapping Table (CMT). As shown in Figure 1, the page-level mapping table is packed into pages (named as translation pages) in the order of Logical data Page Numbers (LPNs) and stored in translation blocks in the flash. The CMT stores the mapping entries (LPN-to-PPN) for those most recently accessed data pages and updates them using the segmented LRU array cache algorithm [28]. The GTD maintains the physical page address information for all the translation pages. One translation page could store 512 mapping entries, if an address is represented in 4 bytes and the page size is 2KB. In this case, the first translation page with $M_{VPN}=0$ stores the mapping information for the first 512 logical pages and so forth, and the location of this translation page will be the first entry in the GTD. Both the CMT and the GTD are stored in the SRAM.

Once a logical request comes, the DFTL will first query the CMT for the mapping information. The request will be directly fulfilled if the mapping is found. Other wise, the DFTL fetches the mapping information from the flash into the CMT by the follow steps: 1) it checks the GTD for the physical location of the corresponding translation page; 2) it reads the translation page for the mapping and adds it into the CMT. A CMT eviction may happen during the above procedure. The evicted item needs to be written back only if it has been changed after loaded. This consists of 3 steps: 1) locate the corresponding translation page by consulting the GTD; 2) read the translation page and write it back to a new physical location with updated information. 3) update the corresponding GTD entry. After the coming logical request is performed, the mapping information may be updated if necessary. Note that it will be always updated in CMT. The update to the translation pages on flash will only happen if a CMT eviction happens.

In DFTL, data pages are written into data blocks whereas translation pages are written into translation blocks. DFTL maintains two blocks called Current Data Block and Current Translation Block for the page allocation. A free block will be chosen as the new Current Data Block or new Current Translation Block from a free block list when pages in either of the two blocks are used up. The garbage collector will choose the block with the least number of active pages as the victim to recycle. If the victim block is a translation block, DFTL copies the active translation pages to the Current Translation Block and update the GTD before erasing the victim block. Otherwise, if the victim is a data block, DFTL relocates the active data pages to the Current Data Block and update the corresponding mapping information in the CMT.

“t-write WOM codes” are WOM codes that can write additional information into the same group of WOM cells multiple ($t$) times (named “1st write, 2nd write”, … ) before requiring an ERASE. Each write requires a read of the existing physical state context, a proper encoding of the new logical data (“message”) using this context, and finally a physical write of the encoded result. The logical message encoded in the 1st write is called “1st message” and the encoded result is called “1st WOM write codeword’, and so forth. For the sake of simplicity, and w.l.o.g. we consider only 2-write WOM code which has the same message space in both writes in the rest of the paper.

Let $c_{i}\in C$ – where $C=\{0,1\}^{n}$ and $1\leq i\leq 2^{n}$ – denote the WOM write codewords of a n-bit WOM code. For example, for the WOM code example in Table I, we have $C=\{c_{1}=000,c_{2}=001,c_{3}=010,c_{4}=011,c_{5}=100,c_{6}=101,c_{7}=110,c_{8}=111\}$.

For any two elements $c_{x},c_{y}\in C$, the relationship $c_{x}\unrhd c_{y}$ is defined by the condition that $c_{x}[i]\geq c_{y}[i]$ for all $i\in[1,n]$, where $c[i]$ is the $i$-th bit of $c$. This is related to the fact that an unset flash bit can be easily set without requiring a page ERASE but not vice-versa. Then, a general definition for a 2-write WOM code can be given as follows [51]:

Informally, for the 1st write, any message is associated with a unique WOM write codeword. The 2nd write is a bit more tricky since the 2nd WOM write codeword to be written depends not only on the 2nd message but also on the existing data (1st WOM write codeword) present in that location. Different values may end up being written i.e., $\mathcal{E}_{2}(m,c_{i})$ may be different from $\mathcal{E}_{2}(m,c_{j})$ for $c_{i}\neq c_{j}$. As a result, one message could be represented by more than one possible WOM write codeword after the 2nd write. For example, wrt. Table I, the message $00$ is always written as $000$ in the 1st write, but in the 2nd write it may be represented as either $000$, if the 1st written message was $00$, or $111$ otherwise.

$\mathcal{E}_{2}()$ may have many different forms. We discovered multiple WOM codes that can represent a message using multiple WOM write codewords in the 2nd write. Our insight then is to use this degree of freedom in the choice of the WOM write codeword in the 2nd write to encode hidden information sureptitiously. For example, two WOM write codeword choices enable the encoding of one hidden bit. Generally, a choice of $2^{m}$ WOM write codewords allow the encoding of $m$ hidden bits. A simple encoding convention would be that using the $i$-th WOM write codeword choice indicates an encoded hidden value of $i$.

In the rest of this paper, for simplicity, and w.l.o.g. we consider WOM codes with two choices only, i.e., which can encode one hidden bit through the encoding of each $k$ bit (public) message. These WOM codes have the following properties: (i) each message can be mapped to 2 WOM write codewords in the 2nd write, and (ii) each codeword is corresponding to a few 1st WOM write codewords. We call these WOM codes WOM Codes Supporting A 1st Partition:

Note that for a valid 2-write WOM code – which requires $\mathcal{E}_{2}(m,c)\unrhd c$ – we must have $\mathsf{w}_{a}(m)\unrhd c_{a}$ for any $c_{a}\in A_{m}$ and $\mathsf{w}_{b}(m)\unrhd c_{b}$ for any $c_{b}\in B_{m}$.

Specifically, we call a WOM code supporting a 1st partition where $|A_{m}|=|B_{m}|$ for all $m\in\{0,1\}^{k}$, a WOM code supporting an equal partition.

Table I illustrates a WOM code supporting a 1st partition, but not an equal partition. Consider $C_{1}=\{c_{1}=000,c_{2}=001,c_{3}=010,c_{4}=100\}$. For each message $m$, $A_{m}=\{\mathcal{E}_{1}(m)\}$, and $B_{m}=C_{1}\setminus A_{m}$, $w_{a}(m)$ and $w_{b}(m)$ are the WOM write codewords in the row corresponding to message $m$ where $w_{a}(m)$ is in the second column and $w_{b}(m)$ is in the third column. It can be seeen that $|A_{m}|=1$ and $|B_{m}|=3$ for any message $m$. Thus, the WOM code does not support an equal partition.

As we will see later, the ability to support an equal partition enables the design of a plausible deniability mechanism in which the resulting distribution of the written bits does not leak information about the encoded hidden data.

As discussed above, for a WOM code supporting a 1st partition, encoding a “hidden” data bit $h$ within a $k$-bit “public” message $p$ can be achieved by using the bit to decide on the choice of WOM write codeword to write in the 2nd write.

Then, more generally, the written data $\mathcal{E}(p,h)$ is a function of both the public message $p$ and the hidden message $h$. Further as we will see, there exists a relationship between the existing data $c$ and the resulting encoding.

We call the encoded result the “full write codeword’ and the write of the full write codeword is called a “full write” to distinguish it from a 2nd write of a public-only message. Then, the corresponding simplified encoding function is:

As mentioned earlier, for simplicity, and w.l.o.g. we consider WOM codes with two 2nd WOM write codewords choices only (as in equation 1), i.e., which can encode one single hidden bit with each $k$ bit (public) message.

Unfortunately there are no free lunches and, as will be detailed later, the full write codeword can only be written to empty pages with all 0s. In other words, one page cannot be written-to twice anymore. Effectively, the hidden bit is encoded at the cost of the ability of the WOM code to accept additional information before the next ERASE.

Note that one of $w_{a}(p)$ and $w_{b}(p)$ are written regardless of the existing data $c$. And, as discussed above, for a valid 2-write WOM code – which requires $\mathcal{E}_{2}(m,c)\unrhd c$ – we must have $\mathsf{w}_{a}(p)\unrhd c$ and $\mathsf{w}_{b}(p)\unrhd c$ for all possible $p$. This is only possible if the existing data $c$ is all 0s, i.e., the encoding works only on empty physical pages, and pages can only be written once before requiring an ERASE.

Table II adds the hidden bit encoding cases to the WOM code in Table I. Between ERASEs, 3 flash cells can be written to either: (i) twice with 2-bit public messages or once with a 2-bit public message and a 1-bit hidden message.

The first case corresponds to public-only operation in which the same set of cells can be reused for a 2nd write between ERASEs and the second case corresponds to the case of hidden operation in which hidden messages are to be encoded plausibly deniable.

The first case corresponds to a sequence of public writes, e.g., an initial write and subsequent updates to the same location. Starting with an empty page (e.g., of 3 bits for simplicity), a public message $p_{1}$ can be written into an empty page firstly (as $c_{1}$) in a 1st write (Figure 4). The encoding used is defined by columns 1&2 in Table II. A subsequent public message $p_{2}$ can be written to the same page (as $c_{2}$) in a 2nd write. Columns 1,3 and 4 in Table II determine the final written state, as a function of 1st WOM write codeword $c_{1}$. Note that after the 2nd write the first public message $p_{1}$ will not be available any more. Only $p_{2}$ can be decoded from $c_{2}$.

In the second hidden operation case, both public ($p_{2}$) and hidden ($h$) messages determine the encoding that gets written ($c_{2}$) in a full write. $c_{2}$ is determined by columns 1,3, and 4 of Table II. Once written, both $p_{2}$ and $h$ can be decoded from $c_{2}$.

While a step in the right direction, the proposed hidden data encoding results in a bias in the distribution of 1s and 0s in the written data when compared to a public-only operation. This can then be used e.g., by a multi-snapshot adversary to distinguish devices that contain hidden information from devices that do not.

Figure 5 shows a simple example of this bias for the example WOM code in Table II. Consider a 2 bits public message $00$. In public-only operation mode, the message is written in a 2nd write, and the 2nd WOM write codeword will be $000$ if the 1st message residing there was $00$, or $111$ if 1st message there is either $01$, $10$, or $11$. If the 1st message written is overall uniformly distributed, the ratio between the occurrence of $000$ to $111$ in the public-only operation storage device should be 1:3.

However, in the case of a hidden operation, the full write codeword ends up being $000$ for a hidden bit of $0$, or $111$ for a hidden bit of $1$. Thus, for an overall uniformly distributed hidden message, the ratio between the occurrence of $000$ to $111$ in the storage device will be 1:1.

Given this bias, an adversary can do statistic analysis based on the public data on the storage data and observe a difference between the expected and observed distribution of 0s and 1s.

A counter-argument to be made is that the public operation mode was considering the case of two writes, and in practice numerous pages may end up being written only once. This may be true, however, given the existence and benefits of the WOM encoding in the system, it is reasonable to expect that in many cases, the device converges to a state where most cells have been overwritten at least once. Also, while it is true one can plausibly claim the bias was inherent in the data itself, the security argument is weakened overall.

Thus, the question inevitably arises: can we do better? How can we overcome this bias? The answer is WOM codes supporting an equal partition.

To see why that is the case, consider that the bias comes directly from the difference in the probability distribution of 2nd WOM write codeword and full write codeword. Reusing the same group of WOM write codewords in the 2nd write for the hidden data encoding ensures that the 2nd WOM write codewords and full write codewords are indistinguishable by inspecting the individual codes. It is an overall probability distribution that may give the existence of hidden data away.

Note that the probability distribution of 2nd WOM write codeword depends on the number of elements in sets A and B (see equations 1 and 2), while the probability distribution of full write codeword is decided by the distribution of hidden bit $h$. And, since hidden data in a PD system is highly likely to be encrypted, $h$ ends up uniformly distributed.

To eliminate the bias, sets A and B need to contain the same number of elements for any arbitrary messages. In other words, the WOM code needs to support an equal partition.

Table III defines a $(3,5)$ WOM code supporting an equal partition. For public operation, it allows writing 3 bits of data twice to 5 storage cells. In hidden operation, 1 hidden bit and 3 public bits can be encoded together in 5 storage cells.

One invariant for this code is that for each 2nd WOM write codeword $c_{2}$ in the “2nd write” column (sub-columns 3 and 4), there exist four 1st WOM write codewords $c_{1}$ for which $c_{2}\unrhd c_{1}$, i.e., that can be overwritten to get to $c_{2}$. In other words, the size of the sets A or B in this WOM code is 4.

For example, considering $w_{a}=11110$ and $w_{b}=10011$ – both of which can be used to represent public message $m=000$ in a 2nd write during public operations – the corresponding set $A$ is $A_{000}=\{00100,01000,11000,10100\}$, composed of the 1st WOM write codewords for messages $\{3,4,6,7\}$. Similarly, set $B$ is $B_{000}=\{00000,00001,00010,10000\}$ composed of the 1st WOM write codewords for messages $\{0,1,2,5\}$. As a result, both $11110$ and $10011$ are equally likely to appear in the written device state – for either public and/or hidden operation modes.

Based on the WOM code in Table III, we design PEARL, a plausibly deniable FTL that securely processes the I/O request from the upper layers, manages the unavoidable inherent mappings from logical to physical pages and reclaims pages occupied by the obsolete data. More importantly, PEARL ensures that adversaries cannot detect the existence of hidden data by probing multiple device snapshots.

PEARL uses three variables to track candidate pages for writing: a Current Empty Page, a Current UI1 Page, and a TI1 page Queue (TIQ). UI1 pages are I1 pages caused by logical data updates. Whenever the public data in a V1 page gets updated, rather than updating in place, the up-to-date data is written to another page and the V1 page becomes a UI1 page. TI1 pages are I1 pages resulting from TRIM operations that delete data. The deleted data in a TI1 page does not have corresponding up-to-date data in any other pages of the device. We distinguish UI1 from TI1 pages since an adversary can infer when a UI1 page becomes invalid with only one device snapshot (detailed later and in Figure 8). Finally, a free block list (FBL) is used to track empty blocks in the device.

In PEARL UI1 pages have the highest priority to be written to. As a result, since they always get written to first, there ends up being at most one UI1 page in the device, tracked by the Current UI1 Page record. Further, TI1 pages have a higher priority than empty pages to be written to. Overall, public data will be written to an empty page only if the Current UI1 Page is NULL and the TIQ is empty. Figure 7 illustrates the page allocation rule for public data.

In contrast, it should always be the Current Empty Page that is allocated for a hidden data write. This makes it possible for an adversary to infer whether a 2nd write page contains hidden data by inferring whether there exists any I1 page (either UI1 or TI1) when the 2nd write page is written to. Moreover, UI1 pages impose different threats compared to TI1 pages, which can be illustrated with Figure 8 as follow.

For a UI1 page that becomes invalid before any hidden data is written, an adversary would always know that it is invalid when the 2nd write page is written to. This is straightforward if the adversary can observe the UI1 page before writing the 2nd write page. Besides, the example of block 1 in Figure 8 explains that this is also true even if the adversary can access the device only after the hidden data is written.

The upper half of Figure 8 lists snapshots of block 1 over time. The adversary observe the block at time $T_{0}$ and $T_{2}$. All three pages are empty at time $T_{0}$. And they are in state I1, V1 and V2, respectively at time $T_{2}$. The I1 page is a UI1 page as it contains the obsoleted data $p_{0}$ whose corresponding up-to-date data ${p_{0}}^{\prime}$ is in the V1 page. Based on the two snapshots, the adversary can infer that: 1) the first page must be a I1 page right after the second page is written to; 2) the third page should be still empty at that time (since pages in one block are written in order). Thus, the adversary can infer (although not directly observe) that there must exist an intermediate state where the there pages are in state I1, V1 and empty, respectively, which is depicted as the snapshot at time $T_{1}$. In this case, hidden data becomes the only possible reason for public data to reside in the V2 page rather than the I1 page in time $T_{2}$.

On the contrary, an adversary cannot tell whether a TI1 page becomes invalid before or after any hidden data is written as long as she cannot observe the TI1 page before the hidden write happens. This can be demonstrated with the example of block 2 in Figure 8. Similarly, the adversary takes the snapshot at time $T_{0}$ and $T_{2}$. Then she observes the state transition empty $\to$ I1 in the first page, and the state transition empty $\to$ V2 in the second page. The only intermediate state she can infer is that the first page was written to be a V1 page at certain time $T_{1}$. After that, the adversary has zero knowledge about whether the V1 page is invalidated first or the empty page is written first. Thus, it is completely possible for the second page to be the V2 page at time $T_{2}$ without any hidden data, as long as the second page is written before the first page becomes invalid.

Thus, to mitigate the possible leaks caused by I1 pages, two tweaks are used regarding the UI1 page and TI1 page: (i) before writing any hidden data, the Current UI1 Page is filled with public data; and (ii) all TI1 pages in the TIQ are written to (with public data either from user requests or from the block with the least number of valid pages) before on-event adversaries are allowed to take a snapshot. These prevent adversaries from detecting the hidden data by analyzing page allocation patterns.

PEARL tags the least active block(s) (with the least number of valid pages) as the next victim block(s) for garbage collection. As detailed in Section VI, the status of a page – valid/invalid – is independent of the existence and status of hidden data stored in that page. Thus, the selection of victim blocks does not leak any information to the adversary regarding the presence of hidden data.

Once a victim block is selected, PEARL first checks whether the Current UI1 Page is in the victim block. If yes, the Current UI1 Page is set to NULL. Then all the TI1 pages in the victim block are extracted from the TIQ. These two actions prevent data from being written to a block that will be erased soon. Then, up-to-date public and hidden data in the victim block are relocated to new pages using the same mechanism that is employed during write requests.

Specifically, the hidden data in the victim block (if any) can be encoded and written to empty pages together with certain public data, which comes from either the victim block or a new public write request. As a result, the hidden data that is stored with public data that is subsequently deleted is not lost.

Moreover, as hidden data are re-encrypted (semantically secure, randomized) during relocation, an adversary cannot link a particular hidden data to a public data it is stored with before and after garbage collection. In effect, deleting public data stored in a particular page does not impact the security and consistency of the hidden data within.

As discussed in Section IV, PEARL supports both public and hidden data requests. However, crucially, PEARL does not require different interfaces for accessing public and hidden data. Instead, PEARL separates hidden data requests from public data requests by a simple offset convention. Hidden data requests (received through the unchanged FTL interface) address an offset beyond the physical standard device capacity. This signals to PEARL that these requests are addressed to the hidden volume.

Note that an adversary attempting to access hidden data through this interface would have to provide the correct password at boot-time. Otherwise, the system will be unable to decrypt hidden data. As a result, simply having access to the same interface does not provide any advantage to the adversary in detecting the presence of hidden data.

Upon receiving I/O requests from upper layers, PEARL divides the incoming requests into page-level requests first, which are then executed individually. To execute these requests, the first step is a logical-to-physical address translation. PEARL first looks up the logical page address in the cached mapping table CMT. If no hit, either the public or the hidden GTD is queried for the location of the corresponding translation page which contains the target physical page mapping entry which can be used to access the page. The mapping is then also cached in the CMT. If this requires a cache eviction, the least recent used entry will be evicted, resulting an update to its corresponding translation page on the device. And if there is any other mapping entries which belong to the same translation page in the CMT, those entries will be written back to the device simultaneously. It is important to note that the (either public or hidden) translation pages are written just like actual (public or hidden) data pages.

In the case of a public write, after the address translation, PEARL identifies one page for the public data based on the page allocation algorithm in Figure 7. The public data is written to the page following the WOM code based encoding scheme. If the logical address was originally mapped to a valid V1 page (the write request is an update to existing data), the page now transitions to UI1 status and is set to be the Current UI1 Page. If the logical address was originally mapped to a TI1 page, the page is deleted from the TIQ and then set to be the Current UI1 Page. Finally, the mapping entry is cached in the CMT accordingly.

Hidden page writes require public data to “cloak” in: first valid page in the least active public data block. This can then be explained as a simple garbage collection related data relocation. Similarly to the other cases, the corresponding public data mapping information is cached in the CMT. The hidden and the public data are then encoded and written to the Current Empty Page and the CMT is updated accordingly. Finally, the Current Empty Page then becomes the next page in the same block, or the first page of a new empty block if the original Current Empty Page was the last page of a block. The new empty block is selected from the FBL.

For either a public or a hidden page TRIM request, the deleted data is marked as out-of-date. If the deleted public data was in a V1 page, the page is pushed to the TIQ.

Power-loss recovery is not described in DFTL. For simplicity, we assume the physical device comes with standard enterprise grade power loss protection (PLP) backed by capacitors that power up the device for enough time to guarantee caches and other memory resident data structures can be flushed to disk. PEARL adds to standard PLP the requirement to write our hidden and public GTDs on power loss also. We also note that if PLP is not available, all data structures can be reconstructed by traversing the entire disk.

Before encoding, public data and hidden data are first encrypted with different keys using AES-CTR with random IVs. As hidden and public data share physical pages, they can also share the IV in the OOB area of each page.

PEARL was implemented as a core FTL engine in FlashSim [32], a popular flash based storage system simulation framework. FlashSim is an event-driven simulator (similar to DiskSim[13]) and is widely used to study the performance implications of different FTL schemes [50, 53, 18, 19]. Specifically, the evaluated PEARL uses the data encoding scheme based on the (3,5) WOM code as discussed in Section VII. Besides, as a baseline for comparison, DFTL is also implemented and evaluated under the same device settings. In the experiments below, a 64GB SSD[35] is simulated and the parameters used for this simulation are listed in Table IV. The page read, write and erase time are 130 us, 900 us and 10ms, respectively.

Although the physical capacity of the SSD simulated is 64GB, the logical capacity for the public volume and the hidden volume are set to 36GB and 12GB respectively. The difference in capacity is due to the use of the (3,5) WOM code, as discussed above. Comparably, the logical volume size when DFTL is used is 54 GB.

FlashSim starts by simulating an empty SSD. However, it is well known that the overall performance of an SSD degrades with increasing logical capacity utilization. Thus, for an accurate evaluation, it is important to start with the device at a state where it has been fairly used for storing and accessing data for all volumes. This requires two things. First, the SSD should be “full” – most of the physical pages have been written at least once and contains some data (may be invalid data). Only in this case garbage collection can be triggered. Second, the amount of valid data in each volume should be “equivalent” relative to volume capacity. In this case, the write amplification due to the relocation of valid data will be comparable.

Thus, in the initialization phase for the PEARL evaluation, the SSD was filled with random data coming from the first halves of the public and the hidden volumes respectively until most of the physical pages have been written once and at least one garbage collection has been invoked. When evaluating DFTL, the SSD was filled with random data from the first half of the corresponding logical volume.

FlashSim reports a total aggregated response time for each request received. This is a combination of the device service time and the effect of queuing delays. Specifically, the response time not only captures the overhead due to the internal processes in an FTL such as address translation and data encoding, but also factors in the time spent by the request in I/O queues etc.

While in certain cases it may be desirable to eliminate scheduling delays etc. from the performance evaluation, this is not possible in the current simulator and would require further kernel instrumentation and more.

We used both real-world workloads and synthetic workloads to benchmark PEARL and DFTL. To evaluate performance for real world applications, we used three popular enterprise-scale workload traces (Table V). This includes two different I/O traces (Financial1 and Financial2) for an OLTP application running at a financial institution [29], and an I/O trace from a popular search engine (Web Search1) [30]. These traces were particularly selected since (i) their address spaces fit within the capacity of the SSD being simulated, and (ii) they include enough writes to invoke garbage collections.

Moreover, these traces provide different characteristics which capture numerous real-world usage scenarios. For example, Financial1 is write-dominant while Financial2 and Web Search1 are read-dominant. Further, Web Search1 has more sequential accesses compared to Financial2. Financial1 and Financial2 also have smaller request sizes while Web Search1 requests more data per request on average. The overall parameters for the traces are summarized in Table V.

In addition to the real-world workloads, we also used synthetic workloads to test throughout of the system under conditions of heavy load. As shown in Table V, the average request interval arrival time is usually long in real-world applications. As a result, the available device bandwidth is never fully utilized. In order to test maximum throughput, we ran multiple synthetic workloads where large numbers of requests are submitted to the device at the same time (the request interval arrival time is 0). Specifically, 100000 read or write requests are submitted for either public or hidden data, and each of them requests for a data chunk of 16KB. Similarly, the response time is recorded for each request and we calculate the number of request satisfied during each second (IOPS).

The three workloads listed in Table V are benchmarked against different FTLs. Figure 9 illustrates average response times for each workload. The y axis is in log scale and the actual values are provided on top of each column for further clarification.

Generally, I/O requests for hidden data consume more time as compared to public data. Comparing with the baseline (DFTL), the overhead for accessing public data ranges from 6% to 13%, while the overhead for accessing hidden data in each workload varies between 13% to 244%. The higher overhead for hidden data access is expected since the amplification of data size for hidden data is 3x the amplification of public data. Thus, a hidden data operation requires more physical page accesses compared to a public operation requesting the same data size.

Further, the average response time increases with increasing percentage of writes in a particular trace. This is more obvious in the case of hidden data accesses. Specifically, for Web Search1, the reported average response time is comparable to the baseline, since more than 99% of the requests are read requests. On the contrary, the average response time when running Financial1 trace is 2-3x higher than the baseline for hidden data, since most of the requests are writes.

Specifically, we can conclude that hidden write requests bring much higher overhead than public write requests. This can be explained with the following reasons. For public data accesses, the overhead for write operations is incurred primarily when the data is written to a 2nd write page. In this case, the old data in the page needs to be read first. A similar overhead is incurred during hidden writes – the public data that will be stored along with the hidden data needs to be read first. However, as hidden data has a larger amplification due to the WOM code compared to public data, the hidden data may be spread across more pages. And each page of hidden data requires a page of public data to be read. As a result, hidden data writes usually require more page operations than public data writes. In addition, a hidden write also requires updating the map entry for the corresponding public data. This may result in additional page accesses. Thus, overall, the overheads for hidden writes are much higher than the overheads for public writes.

Interestingly, the above results indicate that the additional page operations are the main contributors to performance overhead rather than additional data processing (data encoding etc).

The baseline (DFTL) read throughput is around $8.5*10^{4}$ IOPS and write throughput is around $2.5*10^{4}$ IOPS. PEARL public throughput is around $5*10^{4}$ IOPS for reads and $1.3*10^{4}$ IOPS for writes, while the hidden throughput is $1.7*10^{4}$ IOPS for reads and $2.4*10^{3}$ IOPS for writes. In other words, PEARL throughput is around 60% of the baseline for public data, and 10% – 20% of the baseline for the hidden data.

The performance penalty for public data operations is primarily due to the data amplification resulting from the WOM code: 5 physical bits are used to represent only 3 bits of public data. Meanwhile, additional page reads required during the 2nd write also reduces the write throughput of public data.

Write amplification due to WOM codes also significantly affects the throughput for hidden data operations since 5 physical bits are required for 1 hidden bit. Besides, additional page reads and writes are required for public data that is written together with hidden data and plausibly explains the changes to the device. This explains why the hidden write throughput is around 10% instead of 20% of the baseline.