Re: Kernel recycler [was: ext4 features]

[Jan Engelhardt]

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 <jengelh@xxxxxxxxxxxxxxx>
>To: Jeff V. Merkey <jmerkey@xxxxxxxxxxxxxxxxxxxxx>,
>    Diego Calleja <diegocg@xxxxxxxxx>, Valdis.Kletnieks@xxxxxx
>Cc: Arjan van de Ven <arjan@xxxxxxxxxxxxx>, Tomasz Torcz <zdzichu@xxxxxx>,
>    Helge Hafting <helgehaf@xxxxxxxxxxxxx>,
>    Thomas Glanzmann <sithglan@xxxxxxxxxxxxxxxxxxxx>,
>    Theodore Ts'o <tytso@xxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>
>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 <diegocg@xxxxxxxxx>
>>
>>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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/