Re: ext4 features (salvage)

[Bodo Eggert <7eggert@elstempel.de>]

Matthew Frost <artusemrys@sbcglobal.net> wrote:

> We silently keep files around in many filesystems, at least until
> whatever reclamation process runs.  The delete event doesn't itself
> generally purge the data from disk.  However, this is a matter of simple
> tools doing simple things.  Designing an intentional structure around
> not actually deleting deleted files, but keeping them around just in
> case may be lauded as "user-friendly", but it is counter-intuitive.  It
> is cleverness over clarity, good design smothered under feature demand.

[...]

> If you have to add a "really delete, I mean it" command, you're breaking
> fundamental assumptions.

Even without the patch, you can't guarantee that nobody will create a link
just before the supposed-to-be-final unlink(), or copies the file around.
Having undelete() will just make this risk very obvious.

BTW: If you really want to delete files, use shred.


[...]
> Why add non-free space to the free space count, when we're intentionally
> keeping those files?  If you have to be counter-intuitive, why go the
> second counter of hiding it from the user who "wants us to keep and
> index his deleted files"?

It is free space, but it can be unfreed in order to
a) restore the data (on demand)
b) store new data (automatically, no tool needed)

If b happens before a, it's called bad luck.

This concept is fundamentally different from keeping a recycle bin
of 10 % disksize for each of the 20 users (adding up to 200 % of the
disk size), which is well-known from a colorfull "operating" system.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

http://david.woodhou.se/why-not-spf.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/