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 :-(. 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
