From unknown Thu Aug 14 22:17:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#38168: shred vs. SSD Resent-From: Egmont Koblinger Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Mon, 11 Nov 2019 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 38168 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 38168@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.157346501528195 (code B ref -1); Mon, 11 Nov 2019 09:37:02 +0000 Received: (at submit) by debbugs.gnu.org; 11 Nov 2019 09:36:55 +0000 Received: from localhost ([127.0.0.1]:53132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iU67y-0007Kg-F3 for submit@debbugs.gnu.org; Mon, 11 Nov 2019 04:36:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:47617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iU67x-0007KZ-4T for submit@debbugs.gnu.org; Mon, 11 Nov 2019 04:36:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42299) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iU67w-0005lm-1A for bug-coreutils@gnu.org; Mon, 11 Nov 2019 04:36:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iU67v-00081o-3z for bug-coreutils@gnu.org; Mon, 11 Nov 2019 04:36:51 -0500 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]:41502) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iU67v-00081V-0i for bug-coreutils@gnu.org; Mon, 11 Nov 2019 04:36:51 -0500 Received: by mail-qk1-x72e.google.com with SMTP id m125so10581385qkd.8 for ; Mon, 11 Nov 2019 01:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7qOqMgRe44ufJIl1CNpJVtVq1iXTMFUUT+PwGsqji/Y=; b=dKFVOWj6CEhjCTSaWDAFS0D7y/vIdmaezLS7dNg6yZUlJT9AcMD7dTp1W8Uj2/jRIi GNyzAuKCc8x6fwzwEpsmpi8mg8Pq0K08+zj4zRk60gHly80cmQU1VwkfOZ916cNebiuh c5MWWe6jqNVgstuLrt8qCBUT5TWxwWTxBu2cN9NmMi2EeCElc/GZFjHoZnlbNr1SMW7w uZQSM/SVbM6QJXS1SX1n0ki/Q8TnkIRAwftsV6hHXojPWhgASIcaGUvtlwYewcFDyJXd /xbqh5CBJjjh+7O0/HsRw40Y4kdfDvrojiS4G6YDIU8AirnCsMuh9TQbHmhmyoRtb6dB 0DIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7qOqMgRe44ufJIl1CNpJVtVq1iXTMFUUT+PwGsqji/Y=; b=ipqDJPFsISk2cSaMi0uCcf8pWGoTayUfpLAd706nzON62Txcsc5M+AfOQCPw8xf2wZ rP3Uuve0CzB8FwCh6ic08Y5d3MNpzK6vxXt7ecBjVOQyUS+zHUuiFAzT3qgs5W9bG8cp tpQb1TZnNry1iPcu5mpNaJ2VDOpqaCYek9W9YXrpT7ikJTr67056jwP5VXZIbEJ/T6Z0 0mvb0CsdIWKUjqc9Nu8NMXSEJGEYYWWbRMOjbhwMuG/LRyACd2W6lyuSnsNkDeZ4FpuD wjd6/7f67ofzp3vkY4KhIrt/bg40bCY2T14cWe7I54r2beH0GryW1vAmTNJPI+I01mpW jsAw== X-Gm-Message-State: APjAAAU+oiUGbYqv5J8FCqLpKHnuEGocYiNAs9W+qpFrPDr4kw9weG4h QNlMnoRZZvilohvW9g9BqnPSiU0jUezZN88CZcfCZXgc X-Google-Smtp-Source: APXvYqwHOsv+SoK3+lZ/hAu9bEslItjmpdbaxKzOE23fKi/WYxbPCQw7pL2XYlZ2LDyaI+dALgWsXgANmvTP+ao3Ro4= X-Received: by 2002:a05:620a:1505:: with SMTP id i5mr9700690qkk.64.1573465008705; Mon, 11 Nov 2019 01:36:48 -0800 (PST) MIME-Version: 1.0 From: Egmont Koblinger Date: Mon, 11 Nov 2019 10:36:12 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::72e X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi, shred's man and info pages devote several paragraphs to explain "a very important assumption: that the file system overwrites data in place." However, they don't mention that the underlying storage also has to meet this criterium. In particular, today's widely used SSD drives are known to perform wear leveling, i.e. rearrange the blocks as they please. I think shred's documentation should devote a section to storage media, too. (On a side note, the man and info pages are slightly out of sync. E.g. the info page mentions BFS and NTFS as journaling file systems, the man page doesn't.) thanks a lot, egmont From unknown Thu Aug 14 22:17:46 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Egmont Koblinger Subject: bug#38168: closed (Re: bug#38168: shred vs. SSD) Message-ID: References: <467ba9e2-9586-f81e-14c0-d7c7de238f72@cs.ucla.edu> X-Gnu-PR-Message: they-closed 38168 X-Gnu-PR-Package: coreutils Reply-To: 38168@debbugs.gnu.org Date: Tue, 12 Nov 2019 01:02:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1573520523-16784-1" This is a multi-part message in MIME format... ------------=_1573520523-16784-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #38168: shred vs. SSD which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 38168@debbugs.gnu.org. --=20 38168: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38168 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1573520523-16784-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 38168-done) by debbugs.gnu.org; 12 Nov 2019 01:01:20 +0000 Received: from localhost ([127.0.0.1]:56166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUKYZ-0004Lj-4n for submit@debbugs.gnu.org; Mon, 11 Nov 2019 20:01:19 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:55460) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUKYW-0004LW-IB for 38168-done@debbugs.gnu.org; Mon, 11 Nov 2019 20:01:18 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3B9A21604F1; Mon, 11 Nov 2019 17:01:10 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NUhTGEMIeEt3; Mon, 11 Nov 2019 17:01:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 4EAC71604F5; Mon, 11 Nov 2019 17:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0USVlkQE2_Fm; Mon, 11 Nov 2019 17:01:08 -0800 (PST) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 203571604F1; Mon, 11 Nov 2019 17:01:08 -0800 (PST) Subject: Re: bug#38168: shred vs. SSD To: Egmont Koblinger References: From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <467ba9e2-9586-f81e-14c0-d7c7de238f72@cs.ucla.edu> Date: Mon, 11 Nov 2019 17:01:07 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------6608C882AAFFDE01D91266E3" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 38168-done Cc: 38168-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------6608C882AAFFDE01D91266E3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Thanks for mentioning this. I installed the attached patch to fix the problems that you mentioned, except that I didn't add a section on storage media, data remanence, and data forensics (partly because a lot of this stuff is secret). If someone would like to contribute text in that area, it would be a good thing to have (if only to discourage even more users from using 'shred' :-). In the meantime I'll take the liberty of closing the bug report. --------------6608C882AAFFDE01D91266E3 Content-Type: text/x-patch; name="0001-shred-modernize-documentation.patch" Content-Disposition: attachment; filename="0001-shred-modernize-documentation.patch" Content-Transfer-Encoding: quoted-printable >From adf41d7c1e8adf11857ee53d51419e218dcd8804 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 11 Nov 2019 16:52:47 -0800 Subject: [PATCH] shred: modernize documentation MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * doc/coreutils.texi (shred invocation): Modernize discussion to today=E2=80=99s technology (Bug#38168). * src/shred.c (usage): Omit lengthy duplication of the manual=E2=80=99s discussion of file systems and storage devices, as that became out of sync with the manual. Instead, just cite the manual. --- doc/coreutils.texi | 152 ++++++++++++++++++++++++++------------------- src/shred.c | 42 ++----------- 2 files changed, 93 insertions(+), 101 deletions(-) diff --git a/doc/coreutils.texi b/doc/coreutils.texi index b552cc105..32ddba597 100644 --- a/doc/coreutils.texi +++ b/doc/coreutils.texi @@ -9877,7 +9877,7 @@ by POSIX. =20 @emph{Warning}: If you use @command{rm} to remove a file, it is usually possible to recover the contents of that file. If you want more assuran= ce -that the contents are truly unrecoverable, consider using @command{shred= }. +that the contents are unrecoverable, consider using @command{shred}. =20 The program accepts the following options. Also see @ref{Common options= }. =20 @@ -10019,51 +10019,46 @@ predates the development of the @code{getopt} s= tandard syntax. @cindex erasing data =20 @command{shred} overwrites devices or files, to help prevent even -very expensive hardware from recovering the data. - -Ordinarily when you remove a file (@pxref{rm invocation}), the data is -not actually destroyed. Only the index listing where the file is -stored is destroyed, and the storage is made available for reuse. -There are undelete utilities that will attempt to reconstruct the index -and can bring the file back if the parts were not reused. - -On a busy system with a nearly-full drive, space can get reused in a few -seconds. But there is no way to know for sure. If you have sensitive -data, you may want to be sure that recovery is not possible by actually -overwriting the file with non-sensitive data. - -However, even after doing that, it is possible to take the disk back -to a laboratory and use a lot of sensitive (and expensive) equipment -to look for the faint ``echoes'' of the original data underneath the -overwritten data. If the data has only been overwritten once, it's not -even that hard. +extensive forensics from recovering the data. + +Ordinarily when you remove a file (@pxref{rm invocation}), its data +and metadata are not actually destroyed. Only the file's directory +entry is removed, and the file's storage is reclaimed only when no +process has the file open and no other directory entry links to the +file. And even if file's data and metadata's storage space is freed +for further reuse, there are undelete utilities that will attempt to +reconstruct the file from the data in freed storage, and that can +bring the file back if the storage was not rewritten. + +On a busy system with a nearly-full device, space can get reused in a fe= w +seconds. But there is no way to know for sure. And although the +undelete utilities and already-existing processes require insider or +superuser access, you may be wary of the superuser, +of processes running on your behalf, or of attackers +that can physically access the storage device. So if you have sensitive +data, you may want to be sure that recovery is not possible +by plausible attacks like these. =20 The best way to remove something irretrievably is to destroy the media it's on with acid, melt it down, or the like. For cheap removable media -like floppy disks, this is the preferred method. However, hard drives -are expensive and hard to melt, so the @command{shred} utility tries -to achieve a similar effect non-destructively. - -This uses many overwrite passes, with the data patterns chosen to -maximize the damage they do to the old data. While this will work on -floppies, the patterns are designed for best effect on hard drives. -For more details, see the source code and Peter Gutmann's paper -@uref{https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html, -@cite{Secure Deletion of Data from Magnetic and Solid-State Memory}}, -from the proceedings of the Sixth USENIX Security Symposium (San Jose, -California, July 22--25, 1996). - -@strong{Please note} that @command{shred} relies on a very important ass= umption: -that the file system overwrites data in place. This is the traditional +this is often the preferred method. However, some storage devices +are expensive or are harder to destroy, so the @command{shred} utility t= ries +to achieve a similar effect non-destructively, by overwriting the file +with non-sensitive data. + +@strong{Please note} that @command{shred} relies on a crucial +assumption: that the file system and hardware overwrite data in place. +Although this is common and is the traditional way to do things, but many modern file system designs do not satisfy thi= s assumption. Exceptions include: =20 @itemize @bullet =20 @item -Log-structured or journaled file systems, such as those supplied with -AIX and Solaris, and JFS, ReiserFS, XFS, Ext3 (in @code{data=3Djournal} = mode), -BFS, NTFS, etc., when they are configured to journal @emph{data}. +Log-structured or journaled file systems, such as ext3/ext4 (in +@code{data=3Djournal} mode), Btrfs, NTFS, ReiserFS, XFS, ZFS, file +systems supplied with AIX and Solaris, etc., when they are configured to +journal data. =20 @item File systems that write redundant data and carry on even if some writes @@ -10080,27 +10075,64 @@ clients. Compressed file systems. @end itemize =20 -In the particular case of ext3 file systems, the above disclaimer applie= s (and -@command{shred} is thus of limited effectiveness) only in @code{data=3Dj= ournal} +For ext3 and ext4 file systems, @command{shred} is less effective +when the file system is in @code{data=3Djournal} mode, which journals file data in addition to just metadata. In both the @code{data=3Dordered} (default) and @code{data=3Dwriteback} modes, -@command{shred} works as usual. Ext3 journaling modes can be changed +@command{shred} works as usual. The ext3/ext4 journaling modes can be c= hanged by adding the @code{data=3Dsomething} option to the mount options for a particular file system in the @file{/etc/fstab} file, as documented in -the mount man page (man mount). +the @command{mount} man page (@samp{man mount}). Alternatively, if +you know how large the journal is, you can shred the journal by +shredding enough file data so that the journal cycles around and fills +up with shredded data. =20 If you are not sure how your file system operates, then you should assum= e -that it does not overwrite data in place, which means that shred cannot +that it does not overwrite data in place, which means @command{shred} ca= nnot reliably operate on regular files in your file system. =20 Generally speaking, it is more reliable to shred a device than a file, -since this bypasses the problem of file system design mentioned above. -However, even shredding devices is not always completely reliable. For -example, most disks map out bad sectors invisibly to the application; if -the bad sectors contain sensitive data, @command{shred} won't be able to -destroy it. +since this bypasses file system design issues mentioned above. +However, devices are also problematic for shredding, for reasons +such as the following: + +@itemize @bullet + +@item +Solid-state storage devices (SSDs) typically do wear leveling to +prolong service life, and this means writes are distributed to other +blocks by the hardware, so ``overwritten'' data blocks are still +present in the underlying device. =20 -@command{shred} makes no attempt to detect or report this problem, just = as +@item +Most storage devices map out bad blocks invisibly to +the application; if the bad blocks contain sensitive data, +@command{shred} won't be able to destroy it. + +@item +With some obsolete storage technologies, +it may be possible to take (say) a floppy disk back +to a laboratory and use a lot of sensitive (and expensive) equipment +to look for the faint ``echoes'' of the original data underneath the +overwritten data. With these older technologies, if the file has been +overwritten only once, it's reputedly not even that hard. Luckily, +this kind of data recovery has become difficult, and there is no +public evidence that today's higher-density storage devices can be +analyzed in this way. + +The @command{shred} command can use many overwrite passes, +with data patterns chosen to +maximize the damage they do to the old data. +By default the patterns are designed for best effect on hard drives usin= g +now-obsolete technology; for newer devices, a single pass should suffice= . +For more details, see the source code and Peter Gutmann's paper +@uref{https://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html, +@cite{Secure Deletion of Data from Magnetic and Solid-State Memory}}, +from the proceedings of the Sixth USENIX Security Symposium (San Jose, +California, July 22--25, 1996). +@end itemize + +@command{shred} makes no attempt to detect or report these problems, jus= t as it makes no attempt to do anything about backups. However, since it is more reliable to shred devices than files, @command{shred} by default do= es not deallocate or remove the output file. This default is more suitable @@ -10198,7 +10230,7 @@ shred does not increase the apparent size of the = file. @opindex -z @opindex --zero Normally, the last pass that @command{shred} writes is made up of -random data. If this would be conspicuous on your hard drive (for +random data. If this would be conspicuous on your storage device (for example, because it looks like encrypted data), or you just think it's tidier, the @option{--zero} option adds an additional overwrite pas= s with all zero bits. This is in addition to the number of passes specified @@ -10206,28 +10238,22 @@ by the @option{--iterations} option. =20 @end table =20 -You might use the following command to erase all trace of the -file system you'd created on the floppy disk in your first drive. -That command takes about 20 minutes to erase a ``1.44MB'' (actually -1440 KiB) floppy. +You might use the following command to erase the file system you +created on a USB flash drive. This command typically takes several +minutes, depending on the drive's size and write speed. On modern +storage devices a single pass should be adequate, and will take one +third the time of the default three-pass approach. =20 @example -shred --verbose /dev/fd0 +shred -v -n 1 /dev/sdd1 @end example =20 Similarly, to erase all data on a selected partition of -your hard disk, you could give a command like this: - -@example -shred --verbose /dev/sda5 -@end example - -On modern disks, a single pass should be adequate, -and it will take one third the time of the default three-pass approach. +your hard disk, you could give a command like the following. =20 @example # 1 pass, write pseudo-random data; 3x faster than the default -shred --verbose -n1 /dev/sda5 +shred -v -n1 /dev/sda5 @end example =20 To be on the safe side, use at least one pass that overwrites using diff --git a/src/shred.c b/src/shred.c index 61052df42..3374e98c0 100644 --- a/src/shred.c +++ b/src/shred.c @@ -208,44 +208,10 @@ The default mode is 'wipesync', but note it can be = expensive.\n\ \n\ "), stdout); fputs (_("\ -CAUTION: Note that shred relies on a very important assumption:\n\ -that the file system overwrites data in place. This is the traditional\= n\ -way to do things, but many modern file system designs do not satisfy thi= s\n\ -assumption. The following are examples of file systems on which shred i= s\n\ -not effective, or is not guaranteed to be effective in all file system m= odes:\n\ -\n\ -"), stdout); - fputs (_("\ -* log-structured or journaled file systems, such as those supplied with\= n\ -AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)\n\ -\n\ -* file systems that write redundant data and carry on even if some write= s\n\ -fail, such as RAID-based file systems\n\ -\n\ -* file systems that make snapshots, such as Network Appliance's NFS serv= er\n\ -\n\ -"), stdout); - fputs (_("\ -* file systems that cache in temporary locations, such as NFS\n\ -version 3 clients\n\ -\n\ -* compressed file systems\n\ -\n\ -"), stdout); - fputs (_("\ -In the case of ext3 file systems, the above disclaimer applies\n\ -(and shred is thus of limited effectiveness) only in data=3Djournal mode= ,\n\ -which journals file data in addition to just metadata. In both the\n\ -data=3Dordered (default) and data=3Dwriteback modes, shred works as usua= l.\n\ -Ext3 journaling modes can be changed by adding the data=3Dsomething opti= on\n\ -to the mount options for a particular file system in the /etc/fstab file= ,\n\ -as documented in the mount man page (man mount).\n\ -\n\ -"), stdout); - fputs (_("\ -In addition, file system backups and remote mirrors may contain copies\n= \ -of the file that cannot be removed, and that will allow a shredded file\= n\ -to be recovered later.\n\ +CAUTION: shred assumes the file system and hardware overwrite data in pl= ace.\n\ +Although this is common, many platforms operate otherwise. Also, backup= s\n\ +and mirrors may contain unremovable copies that will let a shredded file= \n\ +be recovered later. See the GNU coreutils manual for details.\n\ "), stdout); emit_ancillary_info (PROGRAM_NAME); } --=20 2.23.0 --------------6608C882AAFFDE01D91266E3-- ------------=_1573520523-16784-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 11 Nov 2019 09:36:55 +0000 Received: from localhost ([127.0.0.1]:53132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iU67y-0007Kg-F3 for submit@debbugs.gnu.org; Mon, 11 Nov 2019 04:36:54 -0500 Received: from lists.gnu.org ([209.51.188.17]:47617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iU67x-0007KZ-4T for submit@debbugs.gnu.org; Mon, 11 Nov 2019 04:36:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42299) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iU67w-0005lm-1A for bug-coreutils@gnu.org; Mon, 11 Nov 2019 04:36:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iU67v-00081o-3z for bug-coreutils@gnu.org; Mon, 11 Nov 2019 04:36:51 -0500 Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]:41502) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iU67v-00081V-0i for bug-coreutils@gnu.org; Mon, 11 Nov 2019 04:36:51 -0500 Received: by mail-qk1-x72e.google.com with SMTP id m125so10581385qkd.8 for ; Mon, 11 Nov 2019 01:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7qOqMgRe44ufJIl1CNpJVtVq1iXTMFUUT+PwGsqji/Y=; b=dKFVOWj6CEhjCTSaWDAFS0D7y/vIdmaezLS7dNg6yZUlJT9AcMD7dTp1W8Uj2/jRIi GNyzAuKCc8x6fwzwEpsmpi8mg8Pq0K08+zj4zRk60gHly80cmQU1VwkfOZ916cNebiuh c5MWWe6jqNVgstuLrt8qCBUT5TWxwWTxBu2cN9NmMi2EeCElc/GZFjHoZnlbNr1SMW7w uZQSM/SVbM6QJXS1SX1n0ki/Q8TnkIRAwftsV6hHXojPWhgASIcaGUvtlwYewcFDyJXd /xbqh5CBJjjh+7O0/HsRw40Y4kdfDvrojiS4G6YDIU8AirnCsMuh9TQbHmhmyoRtb6dB 0DIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7qOqMgRe44ufJIl1CNpJVtVq1iXTMFUUT+PwGsqji/Y=; b=ipqDJPFsISk2cSaMi0uCcf8pWGoTayUfpLAd706nzON62Txcsc5M+AfOQCPw8xf2wZ rP3Uuve0CzB8FwCh6ic08Y5d3MNpzK6vxXt7ecBjVOQyUS+zHUuiFAzT3qgs5W9bG8cp tpQb1TZnNry1iPcu5mpNaJ2VDOpqaCYek9W9YXrpT7ikJTr67056jwP5VXZIbEJ/T6Z0 0mvb0CsdIWKUjqc9Nu8NMXSEJGEYYWWbRMOjbhwMuG/LRyACd2W6lyuSnsNkDeZ4FpuD wjd6/7f67ofzp3vkY4KhIrt/bg40bCY2T14cWe7I54r2beH0GryW1vAmTNJPI+I01mpW jsAw== X-Gm-Message-State: APjAAAU+oiUGbYqv5J8FCqLpKHnuEGocYiNAs9W+qpFrPDr4kw9weG4h QNlMnoRZZvilohvW9g9BqnPSiU0jUezZN88CZcfCZXgc X-Google-Smtp-Source: APXvYqwHOsv+SoK3+lZ/hAu9bEslItjmpdbaxKzOE23fKi/WYxbPCQw7pL2XYlZ2LDyaI+dALgWsXgANmvTP+ao3Ro4= X-Received: by 2002:a05:620a:1505:: with SMTP id i5mr9700690qkk.64.1573465008705; Mon, 11 Nov 2019 01:36:48 -0800 (PST) MIME-Version: 1.0 From: Egmont Koblinger Date: Mon, 11 Nov 2019 10:36:12 +0100 Message-ID: Subject: shred vs. SSD To: bug-coreutils@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::72e X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi, shred's man and info pages devote several paragraphs to explain "a very important assumption: that the file system overwrites data in place." However, they don't mention that the underlying storage also has to meet this criterium. In particular, today's widely used SSD drives are known to perform wear leveling, i.e. rearrange the blocks as they please. I think shred's documentation should devote a section to storage media, too. (On a side note, the man and info pages are slightly out of sync. E.g. the info page mentions BFS and NTFS as journaling file systems, the man page doesn't.) thanks a lot, egmont ------------=_1573520523-16784-1--