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@xxxxxxxxxxxxx -- 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
