Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: crankypuss <crankypuss@nomail.invalid>
Newsgroups: comp.os.linux.development.system
Subject: Re: shred or scrub
Date: Fri, 18 Apr 2014 09:59:49 -0600
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <liri6m$tk9$1@dont-email.me>
References: <limvgj$tse$1@dont-email.me> <slrnlkvkrl.2p2.kristof@vega.codepro.be> <liqmp7$4md$1@dont-email.me> <liqsf7$6sg$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 18 Apr 2014 16:00:22 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="89019d17acef4f4359b4b6f15c3a6424"; logging-data="30345"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/NS9Uw3pq5TDXVbSmEnFyy5LHXnjCpJWw="
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0
In-Reply-To: <liqsf7$6sg$1@dont-email.me>
Cancel-Lock: sha1:WvVswZ4eFAqFTCLLEmQ1/TAo8I0=
Xref: csiph.com comp.os.linux.development.system:628

On 04/18/2014 03:49 AM, David Brown wrote:
> On 18/04/14 10:12, crankypuss wrote:
>> On 04/17/2014 07:15 AM, Kristof Provost wrote:
>>> On 2014-04-16, Bill Cunningham <nospam@nspam.invalid> wrote:
>>>>      I am using ext4 on my linux. I'm not quite sure of the
>>>> difference in it
>>>> and ext3 but anyway; the shred man page says with the ext3 filesystem
>>>> shred
>>>> cannot be guaranteed to  work.
>>>>
>>> That's because there's no way to guarantee that the file system will
>>> write the new data over the same block as the old data. In fact, in
>>> log-structured file systems (like ZFS, but not ext3/4) the file system
>>> will deliberately not do this.
>>
>> That seems very messed up.
>
> Some filesystems work this way for particular reasons, such as wear
> leveling (for SSDs), better distribution of data across the disk or
> disks, minimal head movement (for HDs), minimising overwrites in flash
> (when combined with background garbage collection), less fragmentation
> on some times of access patterns, better re-use of data with
> copy-on-write, better safety on power failures or unexpected breaks
> (such as with USB flash sticks), cheap snapshots and rollbacks, etc.
>
> There are many different strategies for how to put data onto disks - no
> one size fits all usage.

Understood, however it does seem to leave a security exposure.