On Tue, Feb 26, 2002 at 08:55:17AM -0800, H. Peter Anvin wrote:
> Followup to: <20020226164036.GG4393@matchmail.com>
> By author: Mike Fedyk <mfedyk@matchmail.com>
> In newsgroup: linux.dev.kernel
> >
> > Uhh, no.
> >
> > You have a configurable size for the undelete dirs and you delete a file.
> > Now, that file gets moved to $mountpoint/.undelete. The daemon gets
> > notified through a socket, and it can check to see if it needs to delete any
> > older deleted files to make sure .undelete doesn't get bigger than
> > configured.
> >
> > We're only scanning the dirs upon daemon startup (reminds me of
> > quota... ;), and all other daemon actions are triggered by unlink() writing
> > to a socket. The worst thing that can happen is not seeing your free space
> > immediately, but a few seconds later.
> >
>
> Hence race condition.
But an acceptable one (it's a small delay), unless the daemon dies. :(
>Also, the solution to hard-reserve space seems
> to fundamentally defeat the purpose (IMO).
>
Do you really thing we should be moving files from kernel space? Ok, glibc
could move the files, that'd be ok.
So, (I don't know) how is the kernel going to support undeletion on all
filesystems (ext2/3, reiserfs, vfat, jfs, xfs, and any other writable fs...)
in the exact same way (as seen from userspace...)?
Mike
-
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/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:29 EST