extended attributes

extended attributes

[Russell Coker]

Extended attribute support is apparently in 2.5.x kernels now and will be in 
2.4.20.

When will ReiserFS support extended attributes?

Currently there is discussion about the possibility of using extended 
attributes for SE Linux security context labels, if that goes ahead then I 
will be forced to cease using any file system that lacks such support.

I would like to continue using ReiserFS...

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: extended attributes

[Hans Reiser]

Russell Coker wrote:

>Extended attribute support is apparently in 2.5.x kernels now and will be in 
>2.4.20.
>
>When will ReiserFS support extended attributes?
>
>Currently there is discussion about the possibility of using extended 
>attributes for SE Linux security context labels, if that goes ahead then I 
>will be forced to cease using any file system that lacks such support.
>
>I would like to continue using ReiserFS...
>
>  
>
www.namesys.com/v4/v4.html, look for us to start focussing on that as 
soon as basic reiser4 stuff is stable.

Re: extended attributes

[Manuel Krause]

On 10/24/2002 03:36 AM, Hans Reiser wrote:
> Russell Coker wrote:
> 
>> Extended attribute support is apparently in 2.5.x kernels now and will 
>> be in 2.4.20.
>>
>> When will ReiserFS support extended attributes?
>>
>> Currently there is discussion about the possibility of using extended 
>> attributes for SE Linux security context labels, if that goes ahead 
>> then I will be forced to cease using any file system that lacks such 
>> support.
>>
>> I would like to continue using ReiserFS...
>>
>>  
>>
> www.namesys.com/v4/v4.html, look for us to start focussing on that as 
> soon as basic reiser4 stuff is stable.


BTW, I find the artistic grafic work on these pages great and especially 
find it beautifully "translating" the theories' content sometimes.

Best wishes to the person who created those images for you & ReiserFS  :-)))

Manuel

Re: extended attributes

[Hans Reiser]

Manuel Krause wrote:

> On 10/24/2002 03:36 AM, Hans Reiser wrote:
>
>> Russell Coker wrote:
>>
>>> Extended attribute support is apparently in 2.5.x kernels now and 
>>> will be in 2.4.20.
>>>
>>> When will ReiserFS support extended attributes?
>>>
>>> Currently there is discussion about the possibility of using 
>>> extended attributes for SE Linux security context labels, if that 
>>> goes ahead then I will be forced to cease using any file system that 
>>> lacks such support.
>>>
>>> I would like to continue using ReiserFS...
>>>
>>>  
>>>
>> www.namesys.com/v4/v4.html, look for us to start focussing on that as 
>> soon as basic reiser4 stuff is stable.
>
>
>
> BTW, I find the artistic grafic work on these pages great and 
> especially find it beautifully "translating" the theories' content 
> sometimes.
>
> Best wishes to the person who created those images for you & ReiserFS  
> :-)))
>
> Manuel
>
>
>
Beverly (my Mom) did the drawings, I am trying to get her to do more.

Hans

Re: extended attributes

[Andreas Dilger]

On Oct 23, 2002  19:16 +0200, Russell Coker wrote:
> Extended attribute support is apparently in 2.5.x kernels now and will be in 
> 2.4.20.
> 
> When will ReiserFS support extended attributes?
> 
> Currently there is discussion about the possibility of using extended 
> attributes for SE Linux security context labels, if that goes ahead then I 
> will be forced to cease using any file system that lacks such support.
> 
> I would like to continue using ReiserFS...

I would think that it would be practical to just store the EA data as a
separate file internally, if you are using tail packing.  That avoids
the need to have a separate data format for EAs entirely.

What I would probably do is have an EA pointer from each inode.  It
would just point to a directory and the EAs would be files with the
filename == attribute name.  You can probably do special packing so
that this is stored efficiently...

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Re: extended attributes

[Chris Mason]

On Wed, 2002-10-23 at 21:45, Andreas Dilger wrote:
> On Oct 23, 2002  19:16 +0200, Russell Coker wrote:
> > Extended attribute support is apparently in 2.5.x kernels now and will be in 
> > 2.4.20.
> > 
> > When will ReiserFS support extended attributes?
> > 
> > Currently there is discussion about the possibility of using extended 
> > attributes for SE Linux security context labels, if that goes ahead then I 
> > will be forced to cease using any file system that lacks such support.
> > 
> > I would like to continue using ReiserFS...
> 
> I would think that it would be practical to just store the EA data as a
> separate file internally, if you are using tail packing.  That avoids
> the need to have a separate data format for EAs entirely.
> 
> What I would probably do is have an EA pointer from each inode.  It
> would just point to a directory and the EAs would be files with the
> filename == attribute name.  You can probably do special packing so
> that this is stored efficiently...
> 

The suse kernels include reiserfs extended attribute and acl support
(the bestbits.at interface, reiserfs part by Jeff Mahoney).

We did it without changing the metadata format at all, which means
putting each xattr into a file.  The patches are mired in dependencies
from other parts of the suse kernel, we're trying to pull it all out.  

Until then you can grab the kernels/source at
ftp.suse.com/pub/people/mantel/next (warning, these are the suse
bleeding edge kernels).

-chris

Re: extended attributes

[Russell Coker]

On Thu, 24 Oct 2002 15:05, Chris Mason wrote:
> We did it without changing the metadata format at all, which means
> putting each xattr into a file.  The patches are mired in dependencies
> from other parts of the suse kernel, we're trying to pull it all out.
>
> Until then you can grab the kernels/source at
> ftp.suse.com/pub/people/mantel/next (warning, these are the suse
> bleeding edge kernels).

Unfortunately that will probably conflict with the LSM kernel patch.  LSM 
touches so many things that almost any patch of moderate size will conflict.  
:(

I look forward to seeing this get extracted out in a minimal form.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page

Re: extended attributes

[Jeff Mahoney]

[-- Attachment #1: Type: text/plain, Size: 3178 bytes --]

On Thu, Oct 24, 2002 at 09:05:47AM -0400, Chris Mason wrote:
> On Wed, 2002-10-23 at 21:45, Andreas Dilger wrote:
> > On Oct 23, 2002  19:16 +0200, Russell Coker wrote:
> > > Extended attribute support is apparently in 2.5.x kernels now and wil=
l be in=20
> > > 2.4.20.
> > >=20
> > > When will ReiserFS support extended attributes?
> > >=20
> > > Currently there is discussion about the possibility of using extended=
=20
> > > attributes for SE Linux security context labels, if that goes ahead t=
hen I=20
> > > will be forced to cease using any file system that lacks such support.
> > >=20
> > > I would like to continue using ReiserFS...
> >=20
> > I would think that it would be practical to just store the EA data as a
> > separate file internally, if you are using tail packing.  That avoids
> > the need to have a separate data format for EAs entirely.
> >=20
> > What I would probably do is have an EA pointer from each inode.  It
> > would just point to a directory and the EAs would be files with the
> > filename =3D=3D attribute name.  You can probably do special packing so
> > that this is stored efficiently...
> >=20
>=20
> The suse kernels include reiserfs extended attribute and acl support
> (the bestbits.at interface, reiserfs part by Jeff Mahoney).
>=20
> We did it without changing the metadata format at all, which means
> putting each xattr into a file.  The patches are mired in dependencies
> from other parts of the suse kernel, we're trying to pull it all out. =20
>=20
> Until then you can grab the kernels/source at
> ftp.suse.com/pub/people/mantel/next (warning, these are the suse
> bleeding edge kernels).

    Hey all -

    Sorry for the delay in getting this patch out. There was a bug that for
    some reason didn't occur in the SuSE kernel, and it took me some time to
    finally track it down. The code has completed four days of my
    standard xattr stress load succesfully.

    The stress load I typically run for these patches is:
    * default ACL set in the FS root
    * fs_stress 20
    * stress.sh -n 50
    * myattr.pl, which goes through the stress.sh tree and applies random
                 user xattrs to files until interrupted

    Prerequisites:
    * Chris's data logging patches (ftp://ftp.suse.com/pub/people/mason)
        - For nested transactions
    * Andreas Gruenbacher's acl/ea patches (http://acl.bestbits.at)
        - For the ACL/EA infrastructure

    Two patches to get (ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea)
    * 01-inode_read_write-atomic.diff - dependency in reiserfs_setattr
    * 02-reiserfs-acl.diff - the xattr/acl patches themselves

    A few config options:
    * CONFIG_REISERFS_FS_XATTR - enables xattrs in general for reiserfs
    * CONFIG_REISERFS_FS_XATTR_USER - enables user xattrs for reiserfs
    * CONFIG_REISERFS_FS_POSIX_ACL - enables posix acls for reiserfs

    Questions/comments welcome and appreciated.

    Enjoy.

    The patches were originally attached to this message, but the reiserfs-list
    mailer killed them for being too large. The SuSE ftp site may take a
    little while to update.

    -Jeff

--
Jeff Mahoney
jeffm@suse.com
jeffm@csh.rit.edu

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]