Re: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc
From: Andreas Dilger <hidden>
Date: 2007-05-09 16:54:02
Also in:
linux-fsdevel, linux-xfs, lkml
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.