linux-ext4 - Re: ceph and ext4

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: <5B8CFFA2-F95F-4CE4-9DE0-5D757BB17B81@whamcloud.com>
Date:	Sun, 12 Feb 2012 10:18:46 -0700
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Yehuda Sadeh Weinraub <yehuda.sadeh@...amhost.com>
Cc:	chb@....de,
	"ceph-devel@...r.kernel.org" <ceph-devel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
	Jian Yu <yujian@...mcloud.com>
Subject: Re: ceph and ext4

On 2012-02-11, at 9:05 PM, Yehuda Sadeh Weinraub wrote:
> On Fri, Dec 9, 2011 at 2:24 PM, Andreas Dilger <adilger@...mcloud.com> wrote:
>> 
>> On 2011-12-08, at 3:59 PM, Christian Brunner wrote:
>>> 2011/11/15 Andreas Dilger <adilger@...mcloud.com>:
>>>> Coincidentally, we have someone working in those patches again. The main obstacle for accepting the previous patch as-is was that Ted wanted to add support for "medium-sized" xattrs that are addressed as a string of blocks, instead of via an inode.
>>> 
>>> Did you make progress with this. I'm still having serious trouble with
>>> btrfs and would like to try these.
>> 
>> The latest patches are available at http://review.whamcloud.com/1708, but are based on the RHEL6.1 2.6.32 kernel.  The work to implement "medium-sized" xattrs was more complex than anticipated, and is not finished yet.
>> 
>> The use of external inode xattrs is working, which allows xattr sizes up to 64kB.  The 64kB limit is imposed by the VFS and could potentially be increased.
> 
> I was able to get those compile on a recent kernel.

It would be useful if you could send me the updated patch, if there were
any significant changes.

> One issue that I
> see is that it will only use a separate inode for the xattr if the
> xattr is big enough. However, it may be that we ran out of enough
> space to set a smaller xattr, and in that case we would fail setting
> it even though we'd be able to set a larger xattr.
> Another related issue, is that the number of xattrs that can be used
> is still limited (by what can be indexed in a single block?).

That is true with the current patch.  When the "medium sized" xattrs are
finished, then there will be 64kB of space for xattrs in the external
block(s), which could be both xattr headers and data.

> I think that the first issue is substantial, as it exposes unexpected
> behavior (getting ENOSPC for small sized attrs, while bigger attrs
> succeed). For the second issue, it seems that when only using small
> xattrs it doesn't change anything from the old behavior.



Cheers, Andreas
--
Andreas Dilger                       Whamcloud, Inc.
Principal Lustre Engineer            http://www.whamcloud.com/




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