Message-ID: <44DB6C83.5030402@us.ibm.com>
Date: Thu, 10 Aug 2006 10:27:31 -0700
From: Mingming Cao <cmm@us.ibm.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Andrew Morton <akpm@osdl.org>
CC: linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net,
       linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 8/9] 48-bit block numbers for extended attributes
References: <1155172929.3161.87.camel@localhost.localdomain> <20060809234100.9337162d.akpm@osdl.org>
In-Reply-To: <20060809234100.9337162d.akpm@osdl.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1501
Lines: 37

Andrew Morton wrote:

> On Wed, 09 Aug 2006 18:22:09 -0700
> Mingming Cao <cmm@us.ibm.com> wrote:
> 
> 
>>As we are planning to support 48-bit block numbers for ext4,
>>we need to support 48-bit block numbers for extended attributes.
>>In the short term, we can do this by reuse (on-disk) 16-bit
>>padding (linux2.i_pad1 currently used only by "hurd") as high 
>>order bits for xattr. This patch basically does that.
> 
> 
> Short-term tends to become medium-term, then you're stuck with it.
> 
> What is the plan here?

At the time we discuss how to support 48 bit xattr in the current inode, 
we were thinking about patching ext3, thus it's not likely we will going 
to do a deep surgery on the on-disk ext3 inode itself to have room for 
another 16bit xattr. So the plan at that is to steal some unused bits 
and construct with existing 32bit xattr to come with a 48bit xattr in total.

Given the fact that we are creating a new filesystem ext4, the ideal way 
(long term) probably we should support 64bit xattr in the ext4 inode, 
that is possible. The plan is to focus on support 48bit ext4 first, then 
probably move on next few things that also requires on-disk format 
changes, this is an experiment filesystem at this moment....

Thanks,
Mingming

-
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/