From: Bodo Eggert <7eggert@elstempel.de>
To: artusemrys@sbcglobal.net,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: ext4 features (salvage)
Date: Wed, 05 Jul 2006 16:09:19 +0200 [thread overview]
Message-ID: <E1Fy84X-0000p0-JD@be1.lrz> (raw)
In-Reply-To: <6uVN4-AN-9@gated-at.bofh.it>
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
next prev parent reply other threads:[~2006-07-05 14:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6tVcC-1e1-79@gated-at.bofh.it>
[not found] ` <6tVcC-1e1-81@gated-at.bofh.it>
[not found] ` <6tVcC-1e1-83@gated-at.bofh.it>
[not found] ` <6tWib-2Ly-7@gated-at.bofh.it>
[not found] ` <6uDdv-7bs-3@gated-at.bofh.it>
[not found] ` <6uDGF-7Nj-47@gated-at.bofh.it>
[not found] ` <6uDQb-8e8-9@gated-at.bofh.it>
[not found] ` <6uDQb-8e8-13@gated-at.bofh.it>
[not found] ` <6uE9y-d1-1@gated-at.bofh.it>
[not found] ` <6uPom-87W-23@gated-at.bofh.it>
2006-07-04 12:28 ` ext4 features Bodo Eggert
2006-07-04 15:32 ` Valdis.Kletnieks
[not found] ` <6uRq6-2Dl-9@gated-at.bofh.it>
[not found] ` <6uRJx-30t-5@gated-at.bofh.it>
[not found] ` <6uVN4-AN-9@gated-at.bofh.it>
2006-07-05 14:09 ` Bodo Eggert [this message]
[not found] ` <6uEMp-1gr-41@gated-at.bofh.it>
[not found] ` <6uUo2-6SN-5@gated-at.bofh.it>
[not found] ` <6uW6v-15i-19@gated-at.bofh.it>
[not found] ` <6vfLY-4K5-33@gated-at.bofh.it>
2006-07-05 22:40 ` Bodo Eggert
[not found] ` <6uXYv-3RG-1@gated-at.bofh.it>
[not found] ` <6veG8-350-7@gated-at.bofh.it>
[not found] ` <6vfiU-465-13@gated-at.bofh.it>
[not found] ` <6vmNk-77r-23@gated-at.bofh.it>
[not found] ` <6vnq7-7Tw-55@gated-at.bofh.it>
[not found] ` <6vrN0-5Se-9@gated-at.bofh.it>
[not found] ` <6vBsY-38p-9@gated-at.bofh.it>
2006-07-07 9:38 ` Bodo Eggert
2006-07-07 14:37 ` Trond Myklebust
2006-07-09 9:50 ` Bodo Eggert
2006-07-01 16:33 Thomas Glanzmann
2006-07-01 17:07 ` Tomasz Torcz
2006-07-01 17:47 ` Thomas Glanzmann
2006-07-01 18:17 ` Tomasz Torcz
2006-07-03 20:22 ` Helge Hafting
2006-07-03 20:55 ` Tomasz Torcz
2006-07-03 21:01 ` Arjan van de Ven
2006-07-03 21:46 ` Jeff V. Merkey
2006-07-03 21:25 ` Diego Calleja
2006-07-04 9:22 ` Petr Tesarik
2006-07-04 11:35 ` Peter Zijlstra
2006-07-04 11:55 ` ext4 features (salvage) Petr Tesarik
[not found] ` <80294dc60607040508l1022d164ybe0ba10858e54f0c@mail.gmail.com>
2006-07-04 12:31 ` Petr Tesarik
2006-07-04 12:42 ` Helge Hafting
2006-07-04 16:20 ` Matthew Frost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1Fy84X-0000p0-JD@be1.lrz \
--to=7eggert@elstempel.de \
--cc=7eggert@gmx.de \
--cc=artusemrys@sbcglobal.net \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®