On Mon, May 07, 2007 at 10:06:10AM +1000, Neil Brown wrote:
On Monday May 7, [EMAIL PROTECTED] wrote:
Would you be able to respin that second patch series with one of those
changes?
Of course it is actually the first series of patches that introduces
this problem. So maybe just a full
Andrew,
Thanks for the review comments!
On Thu, May 03, 2007 at 09:29:55PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:33:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch implements the fallocate() system call and adds support for
i386, x86_64 and powerpc.
...
On Thu, May 03, 2007 at 11:28:15PM -0700, Andrew Morton wrote:
The above opengroup page only permits S_ISREG. Preallocating directories
sounds quite useful to me, although it's something which would be pretty
hard to emulate if the FS doesn't support it. And there's a decent case to
be made
On Thu, May 03, 2007 at 09:30:02PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:41:01 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+unsigned int ext4_ext_check_overlap(struct inode *inode,
+ struct ext4_extent *newext,
+
On Thu, May 03, 2007 at 09:31:33PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
This patch has the ext4 implemtation of fallocate system call.
...
+ /* ext4_can_extents_be_merged should have checked that either
+
On Thu, May 03, 2007 at 09:32:38PM -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:46:23 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+ */
+int ext4_ext_try_to_merge(struct inode *inode,
+ struct ext4_ext_path *path,
+ struct
On 4/26/07, Amit K. Arora [EMAIL PROTECTED] wrote:
/*
+ * ext4_ext_try_to_merge:
+ * tries to merge the ex extent to the next extent in the tree.
+ * It always tries to merge towards right. If you want to merge towards
+ * left, pass ex - 1 as argument instead of ex.
+ * Returns 0 if the
On Mon, May 07, 2007 at 03:40:26PM +0300, Pekka Enberg wrote:
On 4/26/07, Amit K. Arora [EMAIL PROTECTED] wrote:
/*
+ * ext4_ext_try_to_merge:
+ * tries to merge the ex extent to the next extent in the tree.
+ * It always tries to merge towards right. If you want to merge towards
+ * left,
Yes. I can do that trivially as long as it does not bore people on
fsdevel. Only three or four big patches had gone in this year.
I had been sending a few of the bigger patches off to lkml and/or jra (the
Samba 3 lead) and /or Shaggy.
Steve French
Senior Software Engineer
Linux Technology
Apologies if this is late
Please pull from the 'server-cluster-locking-api' branch at
git://linux-nfs.org/~bfields/linux.git server-cluster-locking-api
for a series of patches which allow NFS to export the locking
functionality provided by filesystems which define their own -lock()
On Mon, May 07, 2007 at 01:47:02PM -0400, Quentin Godfroy wrote:
I have made another patch, which I hope should not break anything this
time. I tested it on an x86_64 kernel with 32 and 64 bits executables,
PIE and not PIE (well my only PIE are libc-2.5.so and ld-2.5.so). I
rejoined the loops
On May 03, 2007 21:31 -0700, Andrew Morton wrote:
On Thu, 26 Apr 2007 23:43:32 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+ * ext4_fallocate:
+ * preallocate space for a file
+ * mode is for future use, e.g. for unallocating preallocated blocks etc.
+ */
This description is rather
On Mon, 7 May 2007 05:37:54 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
+ block = offset blkbits;
+ max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits) blkbits)
+ - block;
+ mutex_lock(EXT4_I(inode)-truncate_mutex);
+ credits =
Motivation:
Linux currently has 1-2 flash filesystems to choose from, JFFS2 and
YAFFS. The latter has never made a serious attempt of kernel
integration, which may disqualify it to some.
The two main problems of JFFS2 are memory consumption and mount time.
Unlike most filesystems, there is no
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based implementation and an ext3 implementation.
Actually, this is a non-issue. The reason
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that this is the only way to allocate space in the filesystem without
doing the explicit zeroing. For other filesystems (including ext3 and
On Mon, 7 May 2007 19:14:42 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that this is the only way to allocate space in the filesystem without
On Mon, May 07, 2007 at 07:02:32PM -0400, Jeff Garzik wrote:
Andreas Dilger wrote:
On May 07, 2007 13:58 -0700, Andrew Morton wrote:
Final point: it's fairly disappointing that the present implementation is
ext4-only, and extent-only. I do think we should be aiming at an ext4
bitmap-based
On Mon, 2007-05-07 at 13:58 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 05:37:54 -0600
Andreas Dilger [EMAIL PROTECTED] wrote:
+ block = offset blkbits;
+ max_blocks = (EXT4_BLOCK_ALIGN(len + offset, blkbits)
blkbits)
+- block;
+
On Mon, 07 May 2007 17:00:24 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
+ while (ret = 0 ret max_blocks) {
+ block = block + ret;
+ max_blocks = max_blocks - ret;
+ ret = ext4_ext_get_blocks(handle, inode, block,
+
On Mon, 2007-05-07 at 16:31 -0700, Andrew Morton wrote:
On Mon, 7 May 2007 19:14:42 -0400
Theodore Tso [EMAIL PROTECTED] wrote:
On Mon, May 07, 2007 at 03:38:56PM -0700, Andrew Morton wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only
is that
On Mon, 2007-05-07 at 17:15 -0700, Andrew Morton wrote:
On Mon, 07 May 2007 17:00:24 -0700
Mingming Cao [EMAIL PROTECTED] wrote:
+ while (ret = 0 ret max_blocks) {
+ block = block + ret;
+ max_blocks = max_blocks - ret;
+ ret =
On May 07, 2007 19:02 -0400, Jeff Garzik wrote:
Andreas Dilger wrote:
Actually, this is a non-issue. The reason that it is handled for
extent-only is that this is the only way to allocate space in the
filesystem without doing the explicit zeroing.
Precisely /how/ do you avoid the zeroing
Andreas Dilger wrote:
My comment was just that the extent doesn't have to be explicitly zero
filled on the disk, by virtue of the fact that the uninitialized flag
will cause reads to return zero.
Agreed, thanks for the clarification.
Jeff
-
To unsubscribe from this list: send the
On Mon, May 07, 2007 at 05:41:39PM -0700, Mingming Cao wrote:
We could check the total number of fs free blocks account before
preallocation happens, if there isn't enough space left, there is no
need to bother preallocating.
Checking against the fs free blocks is a good idea, since it will
25 matches
Mail list logo
