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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
