Re: posix_fallocate

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Tue, 19 Nov 2013, Christoph Badura wrote:

> On Mon, Nov 18, 2013 at 12:31:41PM +1100, matthew green wrote:
> > i would buy this argument if mmap()ing a large sparse file
> > and filling it up randomly (but with relatively large chunks
> > at a time) did not lead to severely fragmented files that
> > can take 10x to read, vs one written with plain sequential
> > write() calls.
> 
> There's another option that should avoid that behaviour: make the file
> system place the sparse blocks approximately where it would place them
> where they written in sequential order.  One could do the same also
> after an lseek() that creates a hole.
> 
> Such a change should be relatively straightforward for file systems like
> UFS that limit the amount of data that is allocated in a cylinder group on
> sequential writes.

Or... LFS doesn't allocate the actual location of disk blocks until it 
starts the write operation.  ISTR FFS allocates disk locations when the 
data blocks are created.  Maybe FFS should do what LFS does.  It's easier 
to make the blocks contiguous if they're all allocated at the same time.

Eduardo