Position: Data Should Not Be Forever. Data Must Decay!
Paper #150
Abstract
Digital storage is nearly synonymous with persistence and
reliability, and our entire storage stack is designed from the
ground up with the assumption that applications require these
properties to operate. We observe that not only do some ap-
plications not require these properties, they sometimes go to
great lengths to ensure that these properties do not hold. The
source of the problem is that the data lifecycle is merely an af-
terthought - we only think about deleting data after it has been
created, rather than expressing how long the data is needed
when it is created. In this paper, we advance a controversial
position - data should decay by default, and the storage stack
should be reengineered with the mechanisms necessary to
support decaying data. By embracing decay, we will greatly
simplify data management and build a more efficient and
manageable storage stack.
1 Introduction
Storage stacks today are built from the ground up to reliably
persist data and to protect against data loss. Historically, this
design stems from storage devices being fundamentally unre-
liable. Mechanical devices such as tape and disk are prone to
failure, wear and tear as well as bit rot, and even solid state
technologies such as NAND flash are vulnerable to a variety
of idiosyncratic behaviors such as read and program disturb
which introduce errors [1, 2]. One of the primary functions
of today’s storage stack is to protect against these errors and
provide applications with reliable persistence, which is what
users have come to expect [3].
The every layer in the storage stack actively manages er-
rors and abstracts problems away with the assumption that a
storage error is fatal to the layer above it, as shown in Table 1.
For example, device controllers such as a flash translation
layer (FTL) in a SSD manages errors by using error correct-
ing codes and replicating data across flash chips. Storage
interconnects such as NVMe and PCIe protect data through
checksums, and systems such as RAID duplicate data and gen-
erate parity transparently. Many modern filesystems protect
data with checksums, while some even actively scrub data.
Applications themselves may checksum and replicate their
own data. Only unrecoverable errors are propagated up the
1
Layer Sources of Uncorrectable Errors
Application Redundancy, Checksum
Filesystem Metadata, Checksum
Interconnect Link, Checksum
RAID Parity, Redundancy
Device Media, Metadata, ECC
Table 1: To protect data integrity, each layer may replicate or add
parity hidden to the layer above it. Uncorrectable errors occur when
these mechanisms fail. For example, if parity in a RAID deploy-
ment isn’t enough to correct bit errors, then the objects are usually
considered lost.
storage stack. When such errors occur, it is typically assumed
that the application cannot handle the error and that the layers
below are failing and the device should be replaced to prevent
further data loss. At the same time, each layer is free to dupli-
cate and generate metadata to prevent these failures, hidden
to the layers above.
Despite the effort put into the storage stack to ensure that
data is reliably persisted, applications, and often users, some-
times require the exact opposite: assurance that data has been
reliably deleted. Data deletion is no longer just a security and
privacy issue, but also a legal requirement: legislation such
as the General Data Protection Requirement (GDPR) [4] in
Europe and the Health Insurance Portability and Accountabil-
ity Act (HIPAA) [5] and California Consumer Privacy Act
(CCPA) [6] in the United States require that data controllers
and processors adhere to strict rules on how long data can
be kept, and to respect the rights of users who ask that their
data be deleted. These requirements are at odds with a stor-
age stack built to reliably persist data forever. Existing work
has already shown the difficulty of reliably erasing data from
storage devices [7, 8]. In order the ensure the deletion of data,
users must fight with multiple layers of storage abstraction
which transparently duplicate and generate parity which can
be used to reconstruct data.
Moreover, the implicit assumption that a storage stack
should persist data forever error-free limits the efficiency of
storage itself. For example, GDPR requires that companies
keep data no longer than it is needed. Data which is needed
for only 30 days, for example, may not require replication, or
may be able to use weaker error correcting codes compared to
data which is needed to be retained for 10 years. Data center
operators also spend considerable effort trying to predict phys-
ical device failures so that they may be removed before errors
propagate to higher layers in the stack [9, 10, 11, 12, 13, 14],
effort that could be avoided if the persistence requirement is
relaxed. Even the design of physical devices may be different:
for instance, short-term data retention may potentially use
lower programming voltages or different, denser gate designs.
Errors over time may be acceptable for some types of data
and could even be a mechanism for deletion, as data may
be considered deleted once the error rate exceeds a certain
threshold.
We make an argument which some may find controversial:
instead of persisting forever, storage should decay by default.
Our storage systems are littered with data which we have “for-
gotten” to delete. By defaulting to a limited lifespan for data,
we eliminate much of the overhead associated with deleting
and managing data. Defaulting to decay will force users and
developers to think about the data lifecycle as soon as data is
created, rather than deferring the decision to when capacity is
limited or when costs get out of hand.
We argue that supporting this requirement is not a problem
for any one layer in the storage stack. Rather, it is neces-
sary to rethink and redesign the entire storage stack, from
the way devices are built to how the operating system and
filesystems handle errors and how applications leverage them.
The fundamental problem is that each layer of the stack is
designed with the assumption that the layer above it requires
that data is reliably persisted forever. Each layer must be
redesigned to do away with that assumption, and provide flex-
ible persistence and reliability guarantees. Instead of pushing
unrecoverable errors up the stack, we believe that exceptions
should be thrown instead, with the data in the potential case
the higher layers could recover.
This paper takes the following positions:
1. Data should decay by default instead of reliably persist-
ing forever.
2. We must be able to express flexible reliability and per-
sistence requirements to each layer of the storage stack.
3. Each layer of the storage stack should throw exceptions
instead of treating them all errors as unrecoverable.
2 Background
Securely erasing data so that no traces remain has been a
concern of the security community for decades. These con-
cerns are encoded in media sanitization guidelines, such as
the NIST 800-88 guidelines for media sanitization [15]. Early
“secure erase” protocols such as the US DoD 5220.22-M [16]
or the Gutmann 35-Pass Method [17] focused on prevent-
ing the recovery of analog data by writing obfuscation pat-
terns designed to add noise that renders recovery even by
sophisticated means (such as a magnetic force microscope)
2
impossible. Newer devices may implement a “secure erase”
command, which instructs the drive to erase all data, either by
deleting a cryptographic key (known as cryptographic erase)
or physically erasing the data medium, avoiding the need for
overwriting. These methods, however, can be ineffective [8],
due to the presence of over-provisioned area, where data can
hide inaccessible to the user, or devices which fail to imple-
ment erase commands correctly. NIST 800-88 goes as far to
suggest that destroying the device may be the only option if
the device is not reliable.
Secure erase is primarily focused on erasing the entire
device, which is typically only necessary when equipment
changes hands or is near the end of its useful life. More re-
cently, regulations such as the GDPR, HIPAA and CCPA have
begun to require data controllers and processors to keep data
only as long as it necessary. This requirement introduces
the need to track the lifecycle of small amounts of data (i.e.
single records) and erase it on a much more granular basis
than can be met with whole device secure erase methods.
The storage stack already has some support for deleting at
smaller granularities: ATA supports TRIM, and NVMe sup-
ports deallocate, both of which inform the device that a sec-
tor has been freed. Most modern filesystems will send those
commands to the device when a file is deleted, and applica-
tions can inform the filesystem that blocks are no longer neces-
sary through fallocate(2)’s FALLOC_FL_PUNCH_HOLE. Un-
fortunately, very few applications send these commands to
the filesystem, likely for performance reasons. Recent work
has shown that retrofitting existing applications such as Re-
dis and Postgres to be regulation-compliant results in per-
formance slowdowns of 2 − 4× and even space overheads
of 3 − 5× [18, 19]. Issuing these commands may not even
result in actual deletion of all copies of the data: for example,
the NVMe specification explicitly states that these operations
only guarantee that data will no longer be user-accessible,
but copies may still remain in other areas on the disk (over-
provisioned area, bad blocks).
Other works, such as Vanish [20] and Ephemerizer [21, 22]
try to use cryptography to solve the deletion problem. The ba-
sic approach is to encrypt data and throw away the encryption
key when the data should be deleted, also known as crypto-
shredding. Encrypting also ensures limited blast radius of data
breaches, as data cannot be read without key access. While
encryption can provide some guarantees, it is not always prac-
tical due to a reliance on unbreakable schemes [23, 24, 25],
high computational cost of encryption, and a reliance on
trusted key managers. For example, researchers showed that
they were able to break Vanish by attacking the key man-
agers [26], and a centralized key manager is an acknowledged
shortcoming of the Ephemerizer.
2.1 The Problem
The key problem with existing approaches is that deletion is
an afterthought - it is considered at the end of the data lifecycle
rather than the beginning. The contract the application and
user has with the storage stack is that anything that is written
to it must be able to be read back with perfect fidelity forever,
unless deletion is requested.
We know from regulatory requirements that for many com-
panies, this is already not the case. Data is only to be kept as
long as it is needed, and for most data items, the answer is
certainly not forever. For the end user, while the answer may
be forever for some key documents (pictures, an important
letter) it is probably not the case for others (the menu for the
restaurant you ate at last month, or your copy of Linux 2.14).
If we were able to express at the beginning of the data life
cycle how long we needed data for and with what fidelity, the
storage stack may be able to automatically able to manage
this data lifecycle for us. Moreover, by expressing the lifespan
of data when it is created, the need to explicitly delete data,
which can have performance implications, is reduced because
the data will decay on its own through the storage stack. As a
side effect, the storage stack will become more efficient: for
instance, the stack doesn’t need to replicate data which will
be only read several times over the course of an hour, and it
could focus that for data which will be kept for decades.
To address this problem, we believe that data should decay
by default, instead of being reliably persisted forever. This
will force applications and users to take an active role in ex-
pressing what data they want to keep, rather than waiting to
delete files once a device has reached capacity. To effectively
control decay, we will need a method for each layer of the
stack to express reliability and persistence requirements, so
that a user or application can dictate the lifespan of data when
it is created. Finally, instead of treating all errors as unrecov-
erable, devices should throw exceptions, exposing potentially
corrupt data, as it may still be usable by the application or
end user. An application can decide whether such exceptions
can be recoverable or not. This will allow an application to
leverage decaying data and pave the way for self-decaying
data, which reduce the burden of managing the data life cycle
and allow us to build much more efficient devices.
Threat model. We believe that it is also important to con-
sider a threat model when it comes to enforcing persistence
and reliability. For the purposes of this paper, we do not con-
sider secure deletion, which is the process of deleting data
so that is not recoverable by a sophisticated adversary which
may be able to recover data from areas which are not user-
accessible. We assume that each layer of the stack is not
malicious (and will respect the persistence and reliability re-
quirements given).
3
1.0e0
1-Day retention error
Raw Bit Error Rate
1.0e-1 3-Week retention error
3-Month retention error
1.0e-2 Program-Interference error
1.0e-3 Read error
1.0e-4
1.0e-5
1.0e-6
1.0e-7
1.0e-8
100 1000 10000 100000
P/E cycles
Figure 1: Probability of different types of errors, depending on P/E
cycle (age) of the SSD. Program-interference errors occur when
a cell’s voltage is disturbed by the programming of nearby pages.
Similarly, read errors occur when a cell’s voltage is disturbed by
repeated reads to nearby pages. Data reproduced from [1].
3 A Stack for Decaying Data
The storage stack has been designed to persist data forever.
In this section, we first explore how to achieve self-decaying
data at the physical media layer. Then we present policies that
applications would express in the face of such auto-decaying
data. Finally, we propose mechanisms to propagate exceptions
generated by decaying data, thereby enabling enforcement of
the policies.
3.1 Self-Decaying Data
Status Quo. At a high level, SSDs are a number of raw
flash chips encapsulated with a firmware, or Flash Translation
Layer (FTL). In addition to wear leveling, the most important
functionality of the FTL is to abstract read errors at the hard-
ware level from the user. The FTL employs many mechanisms
to moderate the Raw Bit Error Rate (RBER) of raw NAND
flash, which can be as low as 10−6 − 10−7 for new chips and
as high as 10−2 , depending on the type of flash (SLC vs. MLC
vs. TLC vs. QLC, 2D vs 3D) and how old it is – the older a
device, the higher the RBER. The mechanisms try to reduce
the RBER such that the error rate exposed by the device is
at most 10−17 and often enterprise devices have error rates
as low as 10−20 . To give a sense of how low these traditional
error rates are, an error rate of 10−17 − 10−20 means the user
can expect to hit a bit error once in every 10PB - 1EB read
from the device. For a drive size of 1TB, for example, this
means on average the user expects only one error in 10,000
and 10,000,000 full drive reads.
Decay by Default. The main observation behind self-
decaying data is that we can leverage the natural data deletion
mechanisms in raw flash, in the form of the wide variety of
bit errors that can affect NAND. Figure 1 shows the rate of
a variety of possible errors, based on the age of an SSD in
P/E cycles. The measurements in Figure 1 are for an MLC
device that has an advertised lifetime of 3,000 P/E cycles [1],

11 10 00 01
V undervolts can be determined by the data object’s lifetime:
Figure 2: Raw bit errors are caused by voltage mismatches. The red
lines indicate voltage cutoffs that are used to assign a voltage to bits
(in this example, we consider 2-bit cells, which results in 4 possible
values). The dotted lines indicate default voltage distributions. The
solid lines indicate actual voltage distributions, derived from either
charge leakage or undervolting. Any cells with voltages in the shaded
area are misclassified and appear as raw bit errors.
and each of the measured errors can easily generate an RBER
around 10−6 within the lifetime of the device, which is about
one error in every 1MB read. This suggests raw flash errors
can generate enough corruption for data to be considered
deleted, which means that data will eventually self-corrupt
(destruct) without explicit intervention from higher layers.
Incentives. Data that decays by default provides several
nice security guarantees. First, it can defend against buggy
software delete implementations – even if a higher-level delete
is incomplete, the data will eventually rot on the physical me-
dia. Second, self-decaying data can defend against adversarial
data controllers. In particular, it increases the data controller’s
cost of retaining data, forcing controllers to build additional
replication or parity mechanisms at the software level, which
can impact performance and complexity. Third, self-decaying
data also defends against inadvertent data copies. For example,
by the time a third-party indexes personal data, the data might
have decayed sufficiently that the integrity of the original data
is lost, thereby ensuring privacy for the user.
Finally, self-decaying data can help trusty-worthy data-
center operators that are seeking to reduce the total cost of
ownership of their storage, in terms of both hardware and
code complexity of data management.
Mechanisms. To ensure that an SSD is self-decaying, we
first propose removing any part of the FTL that deals with
error correction, turning the device interface into a thin layer
over the underlying raw NAND flash. Note that this is dif-
ferent from proposals such as OpenChannel SSD [27] and
software-defined flash [28], which are platforms that enable
users to implement co-design of tasks such as error-handling
and block placement1 .
Two additional hardware mechanisms would further enable
self-decaying data. First, depending on the lifetime of a data
object, which can be predetermined at creation, the device
can undervolt cells in order to achieve faster degradation. The
error rates shown in Figure 1 are for cells that are charged at
a default voltage threshold to enable highest probability of
1 OpenChannel SSD is a good development platform that we will use to
prototype these FTL modifications.
4
correct read-back. Charge leakage, which reduces the voltage
of a cell and occurs naturally over time as electrons leak due
to imperfect capacitance, is the primary reason for raw bit
errors [1, 2, 29], as shown in Figure 2. By undervolting cells,
the FTL can explicitly mirror the effects of charge leakage
by programming a cell to a voltage that is already less than
the default voltage threshold. The extent to which the FTL
the shorter the lifetime, the more drastic the undervolt. As a
corollary, the device should by default disable charge refresh,
which the device occasionally executes to combat charge
leakage [30].
Second, the device should by default completely eliminate
read retries, which an FTL issues if it cannot correct all the
raw bit errors in a flash page. Typically, the read retry will use
a different read voltage that yields lower raw bit errors [31].
Retries obviously compound the latency of a read by however
many retries are issued, which is why optimizing read retries
receives considerable scrutiny in academia [29, 32, 33]. By
eliminating retries, the FTL can simultaneously enable self-
decaying data while improving device performance.
Finally, to reclaim space and aid in automatic garbage col-
lection, we propose that the FTL mark a time-to-live (TTL)
for every page in the spare area that already exists for every
page in a flash device. In this way, the device is semantically
aware of block lifetimes, which can be in turn used to enforce
application-level retention policies, such as TTL policies in
GDPR [4]. Having the FTL manage object lifetime can be
very efficient, as opposed to enforcing TTL at the application
layer, which can slow down applications by 2 − 4× [18].
3.2 Expressing Persistence Policies
An interesting policy enabled by the self-decaying data mech-
anism is probabilistic deletion guarantees.
inherently enables probabilistic deletion, even without in-
tervening effort.
Current deletion mechanisms are inherently probabilistic
because there is no way of controlling dataflow during the
lifetime of the data. Right now: whatever can be deleted is
guaranteed to be deleted in X days. Instead, everything is
guaranteed to be deleted in P(X) days, where we have some
distribution that gets smaller as X increases.
In this section we discuss a variety of persistence policies
that One of the benefits of our stack is that rocksdb ? No WAL,
in particular Crash consistency is no longer a problem
Postgres – also no WAL. No need for recovery (?)
3.3 Propagating Exceptions
Recent research investigations have observed that upper layers
in the software stack do not, but can and should, correct uncor-
rectable errors from lower layers in the stack [34, 35, 36]. We
argue that propagating exceptions is simple because we can
simply reuse the infrastructure in place to meticulously throw

application
A’
libc + libraries error
junk A’
kernel error error A 5
hardware
(a) (b) (c)
Figure 3: Propagating errors: (a) Currently, with standards such as
the POSIX specification, if an operation results in error, there is
no guarantee regarding data propagation. (b) Instead, we propose
treating errors as exceptions, which contain corrupted data, in the
hopes that higher layers in the stack can resolve the corruption. (c)
Propagating exceptions applies to errors that originate in any layer
of the stack.
and handle uncorrectable errors. The only modification we
have to make is to propagate data alongside the error status,
which would include modifying standards such as POSIX.
For example, currently POSIX makes no guarantees about
data returned in a buffer for a read that ends in error.
We built a preliminary implementation to propagate a spe-
cific kind of hardware error: flash drives have a final CRC32
mechanism that checks the fidelity of a page before it is
handed back to the user. If this CRC32 check fails, then no
data is given to the user, only an error status, even though this
corruption error could potentially be corrected by redundancy
at the application level.
In our implementation, we propagated the corruption error
notification in addition to the corrupted data through a cus-
tom libc that we linked against our custom version of Java’s
HotSpot engine, which throws a custom corruption exception
in the IO package. We emulated the hardware errors with a
special FUSE library [37] that was able to pass data alongside
the corruption notification. With this simple, modified stack,
we were able to propagate exceptions from the hardware to
the application (Java programmer), which would allow ap-
plications to deal with the error with an application-specific
policy. We anticipate that the same methodology can be used
to propagate a variety of errors originating in hardware or any
layer of the stack.
4 Conclusion
For decades, we have built storage stacks which try to persist
data reliably forever, without realizing that applications and
users often don’t need or even want data to persist that long.
In this paper, we argued for rethinking storage by turning the
requirement upside down, forcing data to decay by default and
enabling a choice as to how long data should persist which
5
can be passed down the storage stack. We hope that this paper
opens a discussion on the how we can achieve decaying data,
an effort which will require coordination from all parts of
the storage stack. Data Should Not Be Forever. Data Must
Decay! mechanism
policy
Discussion
desired reliability
We’d like to discuss what kind of policies we can support
with these new mechanisms, and which layer(s) in the stack
(pass-through)
that wedesired
have presented
reliability where it makes sense to enforce these
policies.
We’d also like to discuss the potential benefits of prob-
mechanism
abilistic data deletion guarantees. Regulations are currently
ambiguous about A data deletion guarantees such as time-to-live
+
(TTL) and the ECCright to be forgotten. Current deletion mech-
anisms are inherently probabilistic because there is no way
of controlling dataflow during the lifetime of the data. Right
now: whatever can be deleted is guaranteed to be deleted in X
days. Instead, everything is guaranteed to be deleted in P(X)
days, where we have some distribution that gets smaller as X
increases.
References
[1] Yu Cai, Erich F Haratsch, Onur Mutlu, and Ken Mai. Error patterns
in MLC NAND flash memory: Measurement, characterization, and
analysis. In 2012 Design, Automation & Test in Europe Conference &
Exhibition (DATE), pages 521–526. IEEE, 2012.
[2] Yu Cai, Saugata Ghose, Erich F Haratsch, Yixin Luo, and Onur Mutlu.
Error characterization, mitigation, and recovery in flash-memory-based
solid-state drives. Proceedings of the IEEE, 105(9):1666–1704, 2017.
[3] Postgresql’s handling of fsync() errors is unsafe and risks data loss at
least on xfs. https://www.postgresql.org/message-id/flat/
CAMsr%2BYHh%2B5Oq4xziwwoEfhoTZgr07vdGG%2Bhu%3D1adXx59a
TeaoQ%40mail.gmail.com.
[4] Regulation (eu) 2016/679 of the european parliament and of the council
of 27 april 2016 on the protection of natural persons with regard to the
processing of personal data and on the free movement of such data,
and repealing directive 95/46/ec (general data protection regulation).
https://gdpr-info.eu/. Accessed: February 2020.
[5] Health Insurance Portability and Accountability Act of 1996, pub. l. no.
104-191.
[6] The California Consumer Privacy Act of 2018. California Civil Code,
Section 1798.100.
[7] Joel Reardon, David Basin, and Srdjan Capkun. Sok: Secure data
deletion. In 2013 IEEE symposium on security and privacy, pages
301–315. IEEE, 2013.
[8] Michael Yung Chung Wei, Laura M Grupp, Frederick E Spada, and
Steven Swanson. Reliably erasing data from flash-based solid state
drives. In USENIX Conference on File and Storage Technologies
(FAST), 2011.
[9] Brian D Strom, SungChang Lee, George W Tyndall, and Andrei Khur-
shudov. Hard disk drive reliability modeling and failure prediction.
IEEE Transactions on Magnetics, 43(9):3676–3684, 2007.
[10] Bianca Schroeder and Garth A Gibson. Disk failures in the real world:
What does an MTTF of 1, 000, 000 hours mean to you? In USENIX
Conference on File and Storage Technologies (FAST), 2007.
[11] Bianca Schroeder, Raghav Lagisetty, and Arif Merchant. Flash reliabil-
ity in production: The expected and the unexpected. In 14th USENIX
Conference on File and Storage Technologies (FAST 16), pages 67–80,
2016.
[12] Justin Meza, Qiang Wu, Sanjev Kumar, and Onur Mutlu. A large-scale
study of flash memory failures in the field. In Proceedings of the
2015 ACM SIGMETRICS International Conference on Measurement
and Modeling of Computer Systems, pages 177–190, Portland, Oregon,
2015.
[13] Iyswarya Narayanan, Di Wang, Myeongjae Jeon, Bikash Sharma, Laura
Caulfield, Anand Sivasubramaniam, Ben Cutler, Jie Liu, Badriddine
Khessib, and Kushagra Vaid. SSD failures in Datacenters: What?
When? and Why? In Proceedings of the 9th ACM International on
Systems and Storage Conference, page 7. ACM, 2016.
[14] Sidi Lu, Bing Luo, Tirthak Patel, Yongtao Yao, Devesh Tiwari, and
Weisong Shi. Making disk failure predictions SMARTer! In 18th
USENIX Conference on File and Storage Technologies (FAST 20),
pages 151–167, 2020.
[15] Richard Kissel, Matthew A Scholl, Steven Skolochenko, and Xing Li.
Sp 800-88 rev. 1. guidelines for media sanitization, 2006.
[16] DOE DoD and NRC CIA. Dod 5220.22-m, national industrial security
program operating manual,(january, 1995).
[17] Peter Gutmann. Secure deletion of data from magnetic and solid-state
memory. In Proceedings of the Sixth USENIX Security Symposium,
San Jose, CA, volume 14, pages 77–89, 1996.
[18] Aashaka Shah, Vinay Banakar, Supreeth Shastri, Melissa Wasserman,
and Vijay Chidambaram. Analyzing the impact of GDPR on storage
systems. In 11th USENIX Workshop on Hot Topics in Storage and File
Systems (HotStorage 19), 2019.
[19] Supreeth Shastri, Vinay Banakar, Melissa Wasserman, Arun Kumar,
and Vijay Chidambaram. Understanding and benchmarking the impact
of GDPR on database systems. Proceedings of the VLDB Endowment,
13(7), 2020.
[20] Roxana Geambasu, Tadayoshi Kohno, Amit A Levy, and Henry M
Levy. Vanish: Increasing data privacy with self-destructing data. In
USENIX Security Symposium, volume 316, 2009.
[21] Radia Perlman. The Ephemerizer: Making data disappear, 2005.
[22] Radia Perlman. File system design with assured delete. In Third IEEE
International Security in Storage Workshop (SISW’05), pages 6–pp.
IEEE, 2005.
[23] Nicole Perlroth, Jeff Larson, and Scott Shane. N.s.a. able to foil basic
safeguards of privacy on web. https://www.nytimes.com/2013/
09/06/us/nsa-foils-much-internet-encryption.html.
[24] Thomas C Hales. The NSA back door to NIST. Notices of the AMS,
61(2):190–19, 2013.
[25] Shattered. https://shattered.io/.
[26] Scott Wolchok, Owen S Hofmann, Nadia Heninger, Edward W Felten,
J Alex Halderman, Christopher J Rossbach, Brent Waters, and Emmett
Witchel. Defeating vanish with low-cost sybil attacks against large
DHTs. In NDSS, 2010.
[27] Matias Bjørling, Javier González, and Philippe Bonnet. Lightnvm: The
Linux open-channel SSD subsystem. In 15th USENIX Conference on
File and Storage Technologies (FAST 17), pages 359–374, 2017.
[28] Jian Ouyang, Shiding Lin, Song Jiang, Zhenyu Hou, Yong Wang, and
Yuanzheng Wang. SDF: software-defined flash for web-scale internet
storage systems. In Proceedings of the 19th international conference
on Architectural support for programming languages and operating
systems, pages 471–484, 2014.
[29] Yu Cai, Yixin Luo, Erich F Haratsch, Ken Mai, and Onur Mutlu. Data
retention in MLC NAND flash memory: Characterization, optimization,
and recovery. In 2015 IEEE 21st International Symposium on High
Performance Computer Architecture (HPCA), pages 551–563. IEEE,
2015.
[30] Yu Cai, Gulay Yalcin, Onur Mutlu, Erich F Haratsch, Adrian Cristal,
Osman S Unsal, and Ken Mai. Flash correct-and-refresh: Retention-
aware error management for increased flash memory lifetime. In 2012
IEEE 30th International Conference on Computer Design (ICCD),
pages 94–101. IEEE.
[31] NAND flash media management algorithms. https://
www.flashmemorysummit.com/English/Collaterals/
Proceedings/2016/20160808_PreConfH_Haratsch.pdf.
[32] Qiao Li, Min Ye, Yufei Cui, Liang Shi, Xiaoqiang Li, and Chun Jason
Xue. Sentinel cells enabled fast read for NAND flash. In 11th USENIX
Workshop on Hot Topics in Storage and File Systems (HotStorage 19),
2019.
[33] Yixin Luo, Saugata Ghose, Yu Cai, Erich F Haratsch, and Onur Mutlu.
Heatwatch: improving 3d nand flash memory device reliability by
exploiting self-recovery and temperature awareness. In 2018 IEEE
International Symposium on High Performance Computer Architecture
(HPCA), pages 504–517. IEEE, 2018.
[34] Amy Tai, Andrew Kryczka, Shobhit O Kanaujia, Kyle Jamieson,
Michael J Freedman, and Asaf Cidon. Who’s afraid of uncorrectable bit
errors? Online recovery of flash errors with distributed redundancy. In
2019 USENIX Annual Technical Conference (USENIS ATC 19), pages
977–992, 2019.
[35] Aishwarya Ganesan, Ramnatthan Alagappan, Andrea C Arpaci-
Dusseau, and Remzi H Arpaci-Dusseau. Redundancy does not imply
fault tolerance: Analysis of distributed storage reactions to single errors
and corruptions. In 15th USENIX Conference on File and Storage
Technologies (FAST 17), pages 149–166, 2017.
[36] Ramnatthan Alagappan, Aishwarya Ganesan, Eric Lee, Aws Albargh-
outhi, Vijay Chidambaram, Andrea C Arpaci-Dusseau, and Remzi H
Arpaci-Dusseau. Protocol-aware recovery for consensus-based dis-
tributed storage. ACM Transactions on Storage (TOS), 14(3):1–30,
2018.
[37] FUSE. https://www.kernel.org/doc/html/latest/filesyst
ems/fuse.html.