I’ve been getting this question a lot since I posted several articles on how to securely delete data from Linux or Windows, and how to integrate secure file deletion in Nautilus. Many people have asked whether the journaling done by the filesystem makes these secure-delete tools ineffective. In this article I’ll explain whether this is the case (the answer is, “rarely”) and what you can do to make sure that your secure deletion methods aren’t being foiled by a filesystem journal.
Before continuing, it’s important to understand the question being asked. The issue at hand is filesystem journaling. Most commonly-used filesystems today (such as ext3, ext4, and NTFS) all use a journal to record changes to the filesystem before the actual changes are made to the system. This is done to prevent the system from becoming corrupt in the event of an unexpected shutdown (a power failure or a system crash, for example). By recording the planned modifications in a staging area before they are actually made, the filesystem can then play back the journal on the next bootup and maintain a consistent state, if the system goes down uncleanly.
This presents an obvious concern for secure-deletion tools. If data is written to the journal first, then deleting the primary file isn’t going to do the entire job; in theory, the data would still be recoverable from the journal.
The good news is that by default, most filesystems only record metadata to the journal, and don’t write the data until it actually gets pushed out to its final destination. The metadata includes things like the disk sectors, size, attributes, and so forth. This is the most important information for a filesystem to keep, since if the metadata becomes corrupt, there is a risk that the entire filesystem can become corrupt with it. Losing the data inside a file is an isolated data-loss event; losing an entire filesystem is catastrophic.
For performance reasons, most filesystems specifically do not journal actual file data. While journaling this data would almost completely prevent any corruption, it would come at the cost of having to commit every single write to disk twice (once to the journal, and once to its final location on disk). As such, neither ext3, ext4, or NTFS use journaling for actual file data — by default.
Checking the journaling level of your system is very easy. You’ll want to check both what the filesystem is set to use when it is mounted, as well as the currently-running level. To see the default mounting optins in Linux, you’ll want to take a look at the /etc/fstab file.
You’ll notice here that all the main filesystems are set to use the default filesystem settings, and as stated above, ext3 and ext4 do not journal file data by default (for details, see the ext4 documentation at Kernel.org). If someone had set the filesystem to journal file data, you’d see something similar to this:
Notice here how the setting
data=journal has been appended to the default settings. When this filesystem is mounted, it will be set to record new data to the journal before writing it to its destination on the filesystem.
Now, take a look at the currently-mounted filesystems by running the
Notice that the options for each filesystem are displayed on-screen. Here, the text “data=journal” does not appear because none of the filesystems are mounted in this mode (in fact, they are all mounted with their defaults). With data journaling enabled, you’d see something like:
In this case, we see that
/home/jdeprizi/funland/funPartition is mounted such that it will journal filesystem data.
Essentially, as long as you’re using the default settings, you’re not journaling the actual file data. Therefore, you don’t have to worry about the journal foiling your secure file deletion. But even if we don’t have to worry about the filesystem journal, are there other areas we have to fear? Come back later in the week for a follow-up on this topic, covering some of the other items that you need to take into consideration when you want to securely and completely delete a file. I invite you to subscribe to the RSS feed or newsletter to receive automatic updates when new articles come out, and to leave a comment below with any questions you have about this or any other topic.