lkml.org 
[lkml]   [2007]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc
    On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote:
    > I have the updated patches ready which take care of Andrew's comments.
    > Will run some tests and post them soon.
    >
    > But, before submitting these patches, I think it will be better to finalize
    > on certain things which might be worth some discussion here:
    >
    > 1) Should the file size change when preallocation is done beyond EOF ?
    > - Andreas and Chris Wedgwood are in favor of not changing the
    > file size in this case. I also tend to agree with them. Does anyone
    > has an argument in favor of changing the filesize ?
    > If not, I will remove the code which changes the filesize, before I
    > resubmit the concerned ext4 patch.

    I think there needs to be both. If we don't have a mechanism to
    atomically change the file size with the preallocation, then
    applications that use stat() to work out if they need to preallocate
    more space will end up racing.

    > 2) For FA_UNALLOCATE mode, should the file system allow unallocation
    > of normal (non-preallocated) blocks (blocks allocated via
    > regular write/truncate operations) also (i.e. work as punch()) ?

    Yes. That is the current XFS implementation for XFS_IOC_UNRESVSP, and
    what i did for FA_UNALLOCATE as well.

    > - Though FA_UNALLOCATE mode is yet to be implemented on ext4, still
    > we need to finalize on the convention here as a general guideline
    > to all the filesystems that implement fallocate.
    >
    > 3) If above is true, the file size will need to be changed
    > for "unallocation" when block holding the EOF gets unallocated.

    No - we punch a hole. If you want the filesize to change, then
    you use ftruncate() to remove the blocks at EOF and change the
    file size atomically.

    > 4) Should we update mtime & ctime on a successfull allocation/
    > unallocation ?
    > - David Chinner raised this question in following post:
    > http://lkml.org/lkml/2007/4/29/407
    > I think it makes sense to update the [mc]time for a successfull
    > preallocation/unallocation. Does anyone feel otherwise ?
    > It will be interesting to know how XFS behaves currently. Does XFS
    > update [mc]time for preallocation ?

    No, XFS does *not* update a/m/ctime on prealloc/punch unless the file size
    changes. If the filesize changes, it behaves exactly the same way that
    ftruncate() behaves.

    Cheers,

    Dave.
    --
    Dave Chinner
    Principal Engineer
    SGI Australian Software Group
    -
    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-10 03:03    [W:0.023 / U:59.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site