[lkml]   [2007]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc
On May 09, 2007  21:31 +0530, Amit K. Arora wrote:
> 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()) ?
> - 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.

I would only allow this on FA_ALLOCATE extents. That means it won't be
possible to do this for filesystems that don't understand unwritten
extents unless there are blocks allocated beyond EOF.

> 3) If above is true, the file size will need to be changed
> for "unallocation" when block holding the EOF gets unallocated.
> - If we do not "unallocate" normal (non-preallocated) blocks and we
> do not change the file size on preallocation, then this is a
> non-issue.

Not necessarily. That will just make the file sparse. If FA_ALLOCATE
does not change the file size, why should FA_UNALLOCATE.

> 4) Should we update mtime & ctime on a successfull allocation/
> unallocation ?

I would say yes. If glibc does the fallback fallocate via write() the
mtime/ctime will be updated, so it makes sense to be consistent for
both methods. Also, it just makes sense from the "this file was modified"
point of view.

Cheers, Andreas
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-05-09 18:57    [W:0.296 / U:32.912 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site