From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Allison Subject: Re: fallocate vs ENOSPC Date: Mon, 28 Nov 2011 10:49:40 -0800 Message-ID: <20111128184940.GA5170@samba2> References: <4ECF6D41.2040801@draigBrady.com> <20111125104050.GA26729@infradead.org> <20111127031455.GK5167@thunk.org> <20111127234331.GW2386@dastard> <20111128051054.GZ2386@dastard> <4ED34C66.8050300@draigBrady.com> Reply-To: Jeremy Allison Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: =?iso-8859-1?Q?P=E1draig?= Brady , Dave Chinner , Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Theodore Tso Return-path: Received: from fn.samba.org ([216.83.154.106]:58617 "EHLO lists.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753223Ab1K1Sto (ORCPT ); Mon, 28 Nov 2011 13:49:44 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Nov 28, 2011 at 09:36:18AM -0500, Theodore Tso wrote: >=20 > On Nov 28, 2011, at 3:55 AM, P=E1draig Brady wrote: >=20 > >=20 > > You lucidly detailed issues with 1. which I suppose could be somewh= at > > mitigated by not fallocating < say 1MB, though I suppose file syste= ms > > 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 ma= ke > > sense to expand those cases. >=20 > I'm curious -- why are you so worried about ENOSPC? >=20 > 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 becau= se > 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 yo= u. 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html