Re: fallocate vs ENOSPC

[Jeremy Allison <jra@samba.org>]

On Tue, Nov 29, 2011 at 11:26:29AM +1100, Dave Chinner wrote:
> 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?

Yes, absolutely. We're just trying to provide the Windows
semantics the clients expect.

Jeremy.
--
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