This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, 2015-05-26 at 11:12 +0200, Florian Weimer wrote:
> On 05/22/2015 12:18 PM, Mark Wielaard wrote:
> > At the moment we simply use ftruncate. The problem that is solved by
> > using posix_fallocate is that we are about the write to the memory of an
> > mmapped file. Since ftruncate doesn't guarantee that the backing store
> > is really there we risk getting a SIGBUS if the disk is full and we
> > write to a memory area that hasn't been allocated yet. Since this is in
> > library code, we cannot simply catch the SIGBUS. And we cannot use
> > fallocate since that doesn't guarantee that the backing store is really
> > allocated since it depends on whether the underlying file system support
> > fallocate.
> 
> 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).

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?

> If you absolutely, truly need to use mmap, we need either have to
> provide a way to intercept SIGBUS (perhaps à la SHEâthe technology is
> there, it's just not available to C code in a deeply nested library
> right now), or another mmap flag that prevents the kernel from sending
> SIGBUS, and some way to tell if a mapping had been subject to write
> errors (perhaps revive msync(MS_ASYNC)?).

Yes, having msync report the error instead of having to deal with
signals (which is a pain in a library) would definitely be preferred. Or
any other mechanism to make sure that the mmap backed file area really
exists and/or gets written to the backing store.

> 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? 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?

Thanks,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]