[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1178730446.3815.8.camel@dyn9047017103.beaverton.ibm.com>
Date: Wed, 09 May 2007 10:07:25 -0700
From: Mingming Cao <cmm@...ibm.com>
To: "Amit K. Arora" <aarora@...ux.vnet.ibm.com>
Cc: torvalds@...l.org, akpm@...ux-foundation.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-ext4@...r.kernel.org, xfs@....sgi.com, suparna@...ibm.com
Subject: Re: [PATCH 1/5] fallocate() implementation in i86, x86_64 and
powerpc
On Wed, 2007-05-09 at 21:31 +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.
>
If we chose not to update the file size beyong EOF, then for filesystem
without fallocate() support (ext2,3 currently), posix_fallocate() will
follow the hard way(zero-out) to do preallocation. Then we will get
different behavior on filesystems w/o fallocate() support. It make sense
to be consistent, IMO.
My point of view, preallocation is just a efficient way to allocating
blocks for files without zero-out, other than this, the new behavior
should be consistent with the old way: file size update,mtime/ctime,
ENOSPC etc.
Mingming
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists