Re: [PATCH] fallocate() for FFS

[Chuck Silvers <chuq%chuq.com@localhost>]

On Fri, Sep 26, 2014 at 06:07:21AM +0200, Emmanuel Dreyfus wrote:
> Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
> 
> > Implementing fallocate for FFS seems quite obvious.  Is there anything I
> > missed in the patch below? Is it good enough to commit?
> 
> Updated version that spares some panic by properly calling
> uvm_vnp_setsize(). Any comment?

as I recall, GOP_ALLOC() doesn't initialize the blocks allocated, nor create
any zeroed pages in memory to cover the uninitialized blocks, so the patch
you gave would expose the current contents of the blocks which were allocated,
creating a security problem.

but even ignoring that, the patch doesn't seem to actually work:
"ls -ls" shows that the number of blocks allocated to the file doesn't change.
if the fs is unmounted and mounted again, the file size goes back to what it
was before fallocate was called.

I don't remember the sequence of operations that has to be used to allocate
space in ffs anymore, you could take a look at ffs_write() and do what it does.

the bigger problem is that fallocate() wants a way to record that the blocks
are not initialized, so that reading from those offsets can return zeroes
instead of reading the uninitialized blocks from disk, but the FFS metadata
has no way to represent that.  we would need a change to the FFS on-disk format
for fallocate() to be useful for FFS.

-Chuck