Hm this one did not appear on LKML so I resend it.
On Jul 4 2006 00:01, Jan Engelhardt wrote:
>Date: Tue, 4 Jul 2006 00:01:56 +0200 (MEST)
>From: Jan Engelhardt <[email protected]>
>To: Jeff V. Merkey <[email protected]>,
> Diego Calleja <[email protected]>, [email protected]
>Cc: Arjan van de Ven <[email protected]>, Tomasz Torcz <[email protected]>,
> Helge Hafting <[email protected]>,
> Thomas Glanzmann <[email protected]>,
> Theodore Ts'o <[email protected]>, LKML <[email protected]>
>Subject: Kernel recycler [was: ext4 features]
>
>>>
>> Add a salvagable file system to ext4, i.e. when a file is deleted, you just
>> rename it and move it to a directory called DELETED.SAV and recycle the files
>> as people allocate new ones. Easy to do (internal "mv" of file to another
>> directory) and modification of the allocation bitmaps. Very simple and will
>> pay off big. If you need help designing it, just ask me.
>>
>
>Hey, can you help? I had this idea of a kernel-level 'recyler' (FS-independent)
>a while ago (patch file is March 26 according to my `ls -l`) [1], but I have
>suspended it for the moment because it is a tedius task for API-newcomers
>like me. (I currently have to look at a lot of other kernel code to figure
>out what the proper way of doing things is.)
>
>And it comes with some problems:
>
>- recycled files ("deleted" and moved) shall not count into the user's quota
>
>- rm -Rf bigfatdirectory will keep a lot of files around, therefore we would
> need an extra kthread that kills all files in DELETED.SAV after a tunable
> period.
>
>[1] http://jengelh.hopto.org/recycler.diff
>
>
>>From: Diego Calleja <[email protected]>
>>
>>Easily doable in userspace, why bother with kernel programming
>
>Because not every application will use KDE's trash feature, or will use
>/bin/my_rm or or or. I certainly do not have the time to patch any program out
>there to use /bin/my_rm or my_unlink() function. What about statically compiled
>programs? They call the syscall directly, so there is no way (without
>recompiling - if possible at all) to catch it within userspace.
>
>And what about if knfsd is about to delete a file? Let's assume we cannot trust
>the client, so the only choice here is to have a kernel recycler.
>
>>Much better done in userspace - the kernel can't get this right without
>>some user hinting. For starters, it creates a big security hole in all
>>the code that does an open()/unlink().
>>
>>Also, how do you handle the corner cases? The fact you're adding to the
>>pathname of the file means you might push some long names over the MAXPATHLEN
>>value, and you have to worry about name collisions in the directory, and
>>so on. There's also more subtle leakage issues, such as properly handling
>>the permissions on the files on a multi-user system so users can't rummage
>>each other's trash....
>
>I am aware of these problems, but at least for fun & profit, I would like to
>complete the kernel-level recycler.
>
>
>Jan Engelhardt
>--
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
