Re: fallocate vs ENOSPC

[Dave Chinner <david@fromorbit.com>]

On Mon, Nov 28, 2011 at 10:49:40AM -0800, Jeremy Allison wrote:
> On Mon, Nov 28, 2011 at 09:36:18AM -0500, Theodore Tso wrote:
> > 
> > On Nov 28, 2011, at 3:55 AM, Pádraig Brady wrote:
> > 
> > > 
> > > You lucidly detailed issues with 1. which I suppose could be somewhat
> > > mitigated by not fallocating < say 1MB, though I suppose file systems
> > > could be smarter here and not preallocate small chunks (or when
> > > otherwise not appropriate). We can already get ENOSPC from a write()
> > > after an fallocate() in certain edge cases, so it would probably make
> > > sense to expand those cases.
> > 
> > I'm curious -- why are you so worried about ENOSPC?
> > 
> > You need to check the error returns on write(2) anyway (and it's good
> > programming practice anyways --- don't forget to check on close because
> > some network file systems only push to the network on close, and in
> > some cases they might only get quota errors on the close), so I don't see
> > why using fallocate() to get an early ENOSPC is so interesting for you.
> 
> Unfortunately for Samba, Windows clients will *only* report ENOSPC
> to the userspace apps if the initial fallocation fails. Most of
> the Windows apps don't bother to check for write() fails after
> the initial allocation succeeds.
> 
> We check for and report them back to the Windows client anyway of
> course, but most Windows apps just silently corrupt their data in
> this case.
> 
> That's why we use fallocate() in Samba :-(.

IOWs, what you really want is a space reservation mechanism. You've
only got this preallocate hammer, so you use it, yes?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html