xfs
[Top] [All Lists]

Re: [PATCH 4/5] ext4: fallocate support in ext4

To: "Amit K. Arora" <aarora@xxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH 4/5] ext4: fallocate support in ext4
From: Dave Kleikamp <shaggy@xxxxxxxxxxxxxxxxxx>
Date: Tue, 08 May 2007 09:47:54 -0500
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, torvalds@xxxxxxxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, suparna@xxxxxxxxxx, cmm@xxxxxxxxxx
In-reply-to: <20070508105247.GA1950@xxxxxxxxxxxxxxxxxxxx>
References: <20070417125514.GA7574@xxxxxxxxxxxxxxxxxxxx> <20070418130600.GW5967@xxxxxxxxxxxxxxxxxxxx> <20070420135146.GA21352@xxxxxxxxxxxxxxxxxxxx> <20070420145918.GY355@xxxxxxxxxxxxxxxxxxxxxxxx> <20070424121632.GA10136@xxxxxxxxxxxxxxxxxxxx> <20070426175056.GA25321@xxxxxxxxxxxxxxxxxxxx> <20070426181332.GD7209@xxxxxxxxxxxxxxxxxxxx> <20070503213133.d1559f52.akpm@xxxxxxxxxxxxxxxxxxxx> <20070507120719.GD7012@xxxxxxxxxxxxxxxxxxxx> <1178551477.12900.6.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20070508105247.GA1950@xxxxxxxxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
On Tue, 2007-05-08 at 16:22 +0530, Amit K. Arora wrote:
> On Mon, May 07, 2007 at 10:24:37AM -0500, Dave Kleikamp wrote:
> > On Mon, 2007-05-07 at 17:37 +0530, Amit K. Arora wrote:
> > > On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:

> > > > So we don't implement fallocate on bitmap-based files!  Well that's huge
> > > > news.  The changelog would be an appropriate place to communicate this,
> > > > along with reasons why, or a description of the plan to fix it.
> > > 
> > > Ok. Will add this in the function description as well.
> > > 
> > > > Also, posix says nothing about fallocate() returning ENOTTY.
> > > 
> > > Right. I don't seem to find any suitable error from posix description.
> > > Can you please suggest an error code which might make more sense here ?
> > > Will -ENOTSUPP be ok ? Since we want to say here that we don't support
> > > non-extent files.
> > 
> > Isn't the idea that libc will interpret -ENOTTY, or whatever is returned
> > here, and fall back to the current library code to do preallocation?
> > This way, the caller of fallocate() will never see this return code, so
> > it won't violate posix.
> 
> You are right.
> 
> But, we still need to "standardize" (and limit) the error codes
> which we should return from kernel when we want to fall back on the
> library implementation. The posix_fallocate() library function will have
> to look for a set of errors from fallocate() system call, upon receiving
> which it will do preallocation from user level; or else, it will return
> success/error-code returned by the system call to the user.
> 
> I think we can make it fall back to library implementation of fallocate,
> whenever posix_fallocate() receives any of the following errors from
> fallocate() system call:
> 
> 1. ENOSYS
> 2. EOPNOTSUPP
> 3. ENOTTY        (?)
> 
> Now the question is - should we limit the set of errors for this purpose
> to just 1 & 2 above ? In that case I will need to change the error being
> returned here to -EOPNOTSUPP (from current -ENOTTY).

If you want my opinion, -EOPNOTSUPP is better than -ENOTTY.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center


<Prev in Thread] Current Thread [Next in Thread>