late delete improving undeleting files on reiser4

late delete improving undeleting files on reiser4

[Konstantin Münning]

Hi!

The discussion abot loosing important files made me think about a
fetaure I met and liked on DR-DOS (later Novell DOS but I'm not sure if
they kept this feature) which may be nice in Reiser4 and would probably
need an additional plugin.

I'll call it "late delete" as I can't remember how they called it on
DR-DOS. As I'm not aware of all current features of Reiser4 (not using
it yet) please excuse me if this is already implemented or planned
somewhere.

So when deleting files, instead of directly removing the entries off the
directories and freeing the used blocks, they could be only "marked" for
deletion so undeleting would be easy. That's trivial so far. But the
nice (and tricky) feature would be this to be transparent in means that
when disk space gets used up such marked files would be actually deleted
and the user wouldn't notice a thing (except eventually some overhead
(badly implemented on DR-DOS) but to that later).

As simple as it may sound here it needs much more thinking how to do it
good. Here some things that come to my mind about it:

Disadvantages:
- overhead when disk space has to be reclaimed (late delete)
- increasing fragmentation as "mark-deleted" file space increases
effective disk usage %
- security issues when having bad defaults and/or is poorly configurable
- may need special undelete tool

Advantages:
- undeletes files fast, reliable and easy on mounted fs
- "mark-delete" is fast (see first disadvantage, so it's maybe only
using the needed time later)
- it is transparent up to the point of configuration and actual undelete
- improving media life on medias with limited write cycles (Flash Cards,
...) as data writes would cycle through all of the free space of the media

Improvements:
- having an attribute defining which file is to be "mark-deleted" and
which regularly deleted
- having a directory attribute for this feature in addition of
per-file-attribute as a default for new files
- defining a reclaim-strategy as "delete biggest/smallest files first",
"delete oldest mark-deleted file first" etc.
- having a "keep age" attribute to automatically delete "mark-deleted"
files after some time
- having a "deleted copies" attribute to define/limit how many copies of
the same deleted file has to be kept
- defining a max. fillup percentage for startig to reclaim space. By
this the overhead of reclaiming may be moved to a moment of low disk
usage (except when there is no space left) and the first disadvantage
would be mostly gone.
- tool to manually "purge/clean" some "mark-deleted" files (specific
ones or in a directory/tree)

Other improvements in connection with other plugins:
- compressing "mark-deleted" files
- having a "wipe file" attribute for security which wipes the data
portion of the deleted file (with zeroes, random, ...) before freeing
the blocks (evtl. in combination with the "keep age" attribute above)

As for the implementation the "mark-deleted" files/directories may be
moved to a (hidden) .deleted directory on the fs-root. Dependant on
implementation this may eventually loose the original location of the
file and could disclose otherwise protected files but would reduce the
overhead of the "delete oldest mark-deleted file first" strategy. Of
course having this directory as a kind of metadata listing of the files
and keeping them where they are would do the same but needs more coding.

So far my thoughts. Comments welcome.
-- 
Konstantin Münning

Re: late delete improving undeleting files on reiser4

[Hans Reiser]

I'll take a patch.  Especially since I have proposed much the same in
the past.  I'll discuss it more if someone starts writing one.;-)

Hans

Konstantin Münning wrote:

>Hi!
>
>The discussion abot loosing important files made me think about a
>fetaure I met and liked on DR-DOS (later Novell DOS but I'm not sure if
>they kept this feature) which may be nice in Reiser4 and would probably
>need an additional plugin.
>
>I'll call it "late delete" as I can't remember how they called it on
>DR-DOS. As I'm not aware of all current features of Reiser4 (not using
>it yet) please excuse me if this is already implemented or planned
>somewhere.
>
>So when deleting files, instead of directly removing the entries off the
>directories and freeing the used blocks, they could be only "marked" for
>deletion so undeleting would be easy. That's trivial so far. But the
>nice (and tricky) feature would be this to be transparent in means that
>when disk space gets used up such marked files would be actually deleted
>and the user wouldn't notice a thing (except eventually some overhead
>(badly implemented on DR-DOS) but to that later).
>
>As simple as it may sound here it needs much more thinking how to do it
>good. Here some things that come to my mind about it:
>
>Disadvantages:
>- overhead when disk space has to be reclaimed (late delete)
>- increasing fragmentation as "mark-deleted" file space increases
>effective disk usage %
>- security issues when having bad defaults and/or is poorly configurable
>- may need special undelete tool
>
>Advantages:
>- undeletes files fast, reliable and easy on mounted fs
>- "mark-delete" is fast (see first disadvantage, so it's maybe only
>using the needed time later)
>- it is transparent up to the point of configuration and actual undelete
>- improving media life on medias with limited write cycles (Flash Cards,
>...) as data writes would cycle through all of the free space of the media
>
>Improvements:
>- having an attribute defining which file is to be "mark-deleted" and
>which regularly deleted
>- having a directory attribute for this feature in addition of
>per-file-attribute as a default for new files
>- defining a reclaim-strategy as "delete biggest/smallest files first",
>"delete oldest mark-deleted file first" etc.
>- having a "keep age" attribute to automatically delete "mark-deleted"
>files after some time
>- having a "deleted copies" attribute to define/limit how many copies of
>the same deleted file has to be kept
>- defining a max. fillup percentage for startig to reclaim space. By
>this the overhead of reclaiming may be moved to a moment of low disk
>usage (except when there is no space left) and the first disadvantage
>would be mostly gone.
>- tool to manually "purge/clean" some "mark-deleted" files (specific
>ones or in a directory/tree)
>
>Other improvements in connection with other plugins:
>- compressing "mark-deleted" files
>- having a "wipe file" attribute for security which wipes the data
>portion of the deleted file (with zeroes, random, ...) before freeing
>the blocks (evtl. in combination with the "keep age" attribute above)
>
>As for the implementation the "mark-deleted" files/directories may be
>moved to a (hidden) .deleted directory on the fs-root. Dependant on
>implementation this may eventually loose the original location of the
>file and could disclose otherwise protected files but would reduce the
>overhead of the "delete oldest mark-deleted file first" strategy. Of
>course having this directory as a kind of metadata listing of the files
>and keeping them where they are would do the same but needs more coding.
>
>So far my thoughts. Comments welcome.
>  
>