Re: ext3 and undeletion

[Mike Fedyk <mfedyk@matchmail.com>]

On Tue, Feb 26, 2002 at 06:07:49PM +0100, Martin Dalecki wrote:
> >>For the educated user it was always a pain
> >>in the you know where, to constantly run out of quota space due to
> >>file versioning.
> >>
> >
> >Ahh, so we'd need to chown the files to root (or a configurable user and
> >group) to get around the quota issue.
> 
> Welcome to my kill-file. This just shows that you don't even have basic
> background.
> 

Ok guys,

Maybe you'll respect the ideas coming from Andreas Dilger, as some of you
obviously don't like some of my ideas.

Here goes:

On Feb 25, 2002  13:45 -0800, Mike Fedyk wrote:
> I don't think we need anything very complicated either.
> 
> Here's what it probably should do *in libc*:
>   o trap unlink calls
>     o if link count >= 2 then act normally
>     o if link count == 1 then move file (including directory structure from
>       mount point to $mount_point/.deleted/$path/file)

Well, my idea on this is that you don't check the link count at all.  Why
should it be special if I delete /home/adilger/foo, when it is also linked
to /home/adilger/bar?  If I want to undelete /home/adilger/foo, then I
should be able to.  Since it is on the same filesystem, it doesn't take any
more space in the filesystem to keep this link, and in fact avoids the
race condition entirely.

Only the undelete daemon would do real deletions, everything else would
_always_ do something like:

base=`echo $file | sed "s#$mntpt/##"` 
mv $file $mntpt/.undelete/$base[.timestamp/username/etc]

> The undelete daemon (undeleted) would do:
>   o monitor how full the various deleted directories are (always keep some
>     percentage empty to allow new files to be deleted without overflowing
>     the space configured for undelete)
>   o enforce configurable setting for how much space .undelete will hold
>   o delete any single file that will not fit in .undelete's space no matter
>     how new it is
>   o any other sysadmin notification type of things
> 
> Should the glibc routine interact directly with the undelete daemon so that
> the case of a lot of deletion of large files will be handled faster?
> Otherwise, if you delete a lot of files, df won't show the free space
> getting bigger until undeleted did a rescan of it's undelete dirs and freed
> the old deleted files.

Well, my take on this would be that since we are only ever moving files over
to .undelete, then we are never using up more space than what we are already
using, so we do not need to ever synchronously free space to delete a file.

We could always have unlink() write to a socket (e.g. .undelete/daemon or so)
telling it which file it just deleted, and the daemon sleeps on this socket
until woken to see if it needs to do cleanup.  Having the name of the
recently deleted file passed in allows it to do things like clean up old
copies of that file quickly, etc.

Note also that the "unrm" command would need some smarts so that it can
match against variations of $base, because programs may rename a file,
make a new copy, and then delete the renamed file (e.g. emacs, vi, etc).
It would probably do some sort of regexp on the basename() of the file.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/