Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]

[Florian Weimer <fweimer at redhat dot com>]

On 05/26/2015 12:44 PM, Mark Wielaard wrote:

>> posix_fallocate does not guarantee this, either.  See my patch with the
>> documentation update.  Compression, COW, thin provision all can result
>> in ENOSPC.  And obviously, there can be other I/O errors.
> 
> But that is precisely what we want. We want to get an ENOSPC (or some
> other I/O error as documented for posix_fallocate) before we start
> poking at the mmap backed memory. It seems that is what the glibc
> posix_fallocate guarantees, unlike ftruncate (or fallocate which can
> return an error even though there is space, but the file system just
> doesn't implement fallocate support).

Sorry, what I meant is this: Even if you actually *write* zeros now, the
increasing depth of the storage stack means that this will not reliable
prevent you from getting ENOSPC later (which is reported, in the context
of mmap, as SIGBUS).

> If not posix_allocate, what would you recommend we use to make sure the
> file has a backing store before we start poking at it?

Due to the possibility of copy-on-write storage backends, I don't think
you can get what you want anymore.

>> Thin provisioning etc. has become more common lately, so while
>> posix_fallocate did provide this functionality in the past, it doesn't
>> seem to do it right now.
> 
> I might not understand precisely what you mean by thin-provisioning. But
> wouldn't all fancy new filesystems also support fallocate directly
> anyway?

Thin provisioning often operates at the block layer.  An fallocate call
typically only updates metadata, creating unwritten extents instead of
actually writing out zeros.

> In which case the fallback part doesn't even trigger. And if it
> does trigger then because it touches and explicitly writes any block
> that doesn't have a backing store right now, would get it, doesn't it?

I don't know if anything implements this optimization, but it's possible
that if you write zeros to a thin-provisioned hole (think sparse file at
the block layer), then the device discards the write operation.  It's
definitely an issue with compression.  A block of zeros likely
compresses better than anything you will write later, so you can still
get into an ENOSPC situation.

-- 
Florian Weimer / Red Hat Product Security