lkml.org 
[lkml]   [2007]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 4/5] ext4: fallocate support in ext4
    From
    Date
    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

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-08 16:51    [W:5.173 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site