Date: Tue, 7 Sep 2004 15:48:33 -0700
From: Andrew Morton <akpm@osdl.org>
To: Stephen Tweedie <sct@redhat.com>
Cc: linux-kernel@vger.kernel.org, cmm@us.ibm.com, pbadari@us.ibm.com,
       linuxram@us.ibm.com
Subject: Re: [Patch 4/6]: ext3 reservations: Turn ext3 per-sb reservations
 list into an rbtree.
Message-Id: <20040907154833.4cc8d7a3.akpm@osdl.org>
In-Reply-To: <200409071302.i87D2bDf030921@sisko.scot.redhat.com>
References: <200409071302.i87D2bDf030921@sisko.scot.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1067
Lines: 29

Stephen Tweedie <sct@redhat.com> wrote:
>
>  struct reserve_window {
> -	struct list_head 	rsv_list;
> -	__u32			rsv_start;
> -	__u32			rsv_end;
> +	struct rb_node	 	rsv_node;
> +	__u32			rsv_start;	/* First byte reserved */
> +	__u32			rsv_end;	/* Last byte reserved or 0 */
>  	atomic_t		rsv_goal_size;
>  	__u32			rsv_alloc_hit;
>  };

Takes this structure up to 32 bytes on x86.  That's a moderate amount of
inode bloat for something which is only used when an application currently
has the inode open for writing.

Have you given any thought to dynamic allocation of the above?

And if we were to do that, there are a few things which we could move out
of the ext3 in-core inode and into the above structure, such as
i_next_alloc_block and i_next_alloc_goal.

Does the reservation code work for directory growth, btw?
-
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/