Re: TAKE 972756 - Implement fallocate.

["Bhagi rathi" <jahnu77@xxxxxxxxx>]

Since size log change and data I/O are not binded, it is always possible
that size can reach to the
disk before I/O reaching to the disk. Also, the other problem is because of
speculative allocation.
A write-back allocation can leady to allocation of delayed extents into real
and gets pruned only
close of the file. Before that, we get fallocate, it allocates the exents,
but the extents residing
because of delayed allocation write-back will not have zero'ed content.

Conceptually, fallocate if it intends to change size, it is no way different
from size extending write.
 We do xfs_zero_eof for write and not  in this case. Probably, I am missing
the context of usage of
 fallocate if it has some semantics over-loaded.

-Thanks,
  Bhagi.

On 11/7/07, Nathan Scott <nscott@xxxxxxxxxx> wrote:
>
> On Wed, 2007-11-07 at 07:41 +1100, David Chinner wrote:
> > >  Preallocation happened from 1k to 256k. Now, it looks to me that we
> > have
> > > un-written extents from 4k to 256k. There is no guarantee that data
> > from 1k
> > > to 4k is all zero'es.
>
> That guarantee does exist - when the initial 1K block write is done, the
> end of the block is zeroed (by the kernel write path).  This is always
> done (guaranteed) and is required independently to unwritten extents.
>
> cheers.
>
> --
> Nathan
>
>


[[HTML alternate version deleted]]