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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 11 Feb 2012 20:05:55 -0800
From:	Yehuda Sadeh Weinraub <yehuda.sadeh@...amhost.com>
To:	Andreas Dilger <adilger@...mcloud.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 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. 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?).

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.

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