Re: git: VFS accounting: do not count write operations for removed files

[Aggelos Economopoulos <aoiko@xxxxxxxxxxxxxx>]

On 30/03/2012 06:47 μμ, Francois Tigeot wrote:
> commit 384367d5cc2b4958f659c717b1d3ad7eb755ee2a
> Author: Francois Tigeot<ftigeot@wolfpond.org>
> Date:   Fri Mar 30 10:52:07 2012 +0200
>
>      VFS accounting: do not count write operations for removed files
>
>      * vnode operations can and do happen out-of-order in some circumstances
>        (multi-job builds with make for example)
>
>      * check if the vnode has at least one associated link to be sure it
>        still corresponds to an existing file
>
>      * do not count the write operation if this is not the case

Hello Francois,

it seems to me that this is not the proper way to do accounting. It 
basically gives carte blanche to users to consume as much diskspace as 
they want, as long as they do it by writing to an unlinked file. 
Unlinked files (i.e. files that have been deleted but are still open) 
take up space just like any other file and they can grow just like any 
other file. As an administrator, I would consider this unacceptable.

I think you need to account for writes (and writebacks, mmap() of a 
sparse file can still cause space to get allocated when dirtied memory 
needs to be flushed) to unlinked files. The space should be removed when 
the file is last closed. Though how you'll do that and maintain a 
semblance of consistency in the face of unclean shutdowns is not exactly 
clear to me.

I guess your best bet would be to use callbacks, though you'll have to 
add them in quite a few places in filesystem code, at which point it's 
not at all clear that doing quotas at the vfs layer is a good idea. But 
if that's the way you want to go, I don't think you can brush those 
issues aside.

Hope this helps,
Aggelos