Chris Worley <worleys@xxxxxxxxx> writes:
> On Mon, May 25, 2009 at 7:14 AM, Goswin von Brederlow <goswin-v-b@xxxxxx>
> wrote:
>
>
> Thomas Glanzmann <thomas@xxxxxxxxxxxx> writes:
>
> > Hello Ted,
> >
> >> Yes, it does, sb_issue_discard(). So if you wanted to hook into
> this
> >> routine with a function which issued calls to zero out blocks, it
> >> would be easy to create a private patch.
> >
> > that sounds good because it wouldn't only target the most used
> > filesystem but every other filesystem that uses the interface as
> well.
> > Do you think that a tunable or configurable patch has a chance to
> hit
> > upstream as well?
> >
> > Thomas
>
>
>
>
> I could imagine a device mapper target that eats TRIM commands and
> writes out zeroes instead. That should be easy to maintain outside
> or
> inside the upstream kernel source.
>
>
> Why bother with a time-consuming performance-draining operation? There are
> devices that already support TRIM/discard commands today, and once you discard
> a block, it's completely irretrievable (you'll just get back zeros if you try
> to read that block w/o writing it after the discard).
> Chris
Because you have one of the billions of devices that don't.
Because, iirc, the specs say nothing about getting back zeros.
Because someone could read the raw data from disk and recover your
state secrets.
Because loopback don't support TRIM and compression of the image file
is much better with zeroes.
Because on a crypted device TRIM would show how much of the device is
in used while zeroing out (before crypting) would result in random
data.
Because it is fun?
So many reasons.
MfG
Goswin
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
