lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ECA4282.5020908@whamcloud.com>
Date:	Mon, 21 Nov 2011 20:22:26 +0800
From:	Yu Jian <yujian@...mcloud.com>
To:	tytso@....edu
CC:	Andreas Dilger <adilger@...mcloud.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Yu Jian <yujian@...mcloud.com>
Subject: Increase xattr space by allocating contiguous xattr blocks

Hello Ted,

I'm working on the patches for large xattrs support again based on the 
previous patch made by Kalpak Shah. There are some small issues in the 
previous patch, I'd fix them and rebase the patch on the latest ext4 codes.

Per the thread of 
http://kerneltrap.org/mailarchive/linux-ext4/2009/2/9/4931244, there are 
two features need to be implemented:
1) store large xattr value (with value_size > blocksize) in an external 
xattr inode
2) increase xattr space by allocating a single chunk of up to 64kB (in 
size) contiguous xattr blocks

The first one has been implemented in the previous patch, and I'm 
working on the second one, which would handle "medium-sized" xattrs more 
efficiently.

Now, I've the same question as that in the above thread:
In xattr.{h,c}, all of the macros and functions assume the xattr space 
is contiguous with entries growing downwards and values growing upwards 
(aligned to the end of the space). Especially, the create, replace, 
remove and shift operations of xattrs are all performed inside a 
contiguous buffer. This is no problem with in-inode xattr space and 
single external xattr block which is associated with one block buffer. 
But for multiple xattr blocks, since the data of them would be read into 
different block buffers, which are not contiguous, most of the existing 
macros and functions need to be changed. Is this way acceptable?

In order to make most of the codes remain as-is, we could allocate a 
contiguous large buffer (up to 64kB in size) to handle all of the data. 
However, we have to memcpy the data from block buffers to the large 
buffer, and after the data are changed, we need memcpy the data back to 
block buffers to make the data written into the block device. Is this 
way reasonable?

Could you please give me some suggestions on how to solve this issue?

Thanks!
-- 
Best regards,
Yu Jian
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ