ACL Support

ACL Support

[Mike Young]

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

Hi All,

 

I've been trying to find out information on ACL support in Reiserfs, but
haven't had much luck finding anything but a few exchanges here and there.
There are numerous capabilities within Reiserfs, which I'd like to take
advantage of, but this issue of ACL support is only growing.  The problem
actually consists of trying to store ACLs in a Windows environment.  The
number of ACEs can be quite sufficient that it can require multiple inodes
to store everything.  As an example, XFS has a maximum inode size of 2K,
which is normally fairly sufficient.  However, if I wish to support all of
the Windows ACL set, then 2K is inadequate and 4K would actually be better.
Again, I can use multiple inodes, but this has a significant affect on
performance.  The bottom line is that I love Linux as a server and believe I
should be able to seamlessly support a Windows client.  I just don't want to
be as slow as a Windows server.

 

With that in mind, can someone give me a quick synopsis of how ACLs are
handled in Reiserfs v3 and v4?  Also, if there is a url to the information
I'd appreciate a pointer to it.  Admittedly, I haven't read the man pages.
So, if it's all there, please forgive me.

 

Many thanks,

 

Mike


[-- Attachment #2: Type: text/html, Size: 3453 bytes --]

Re: ACL Support

[Christian Mayrhuber]

On Thursday 01 April 2004 18:50, Mike Young wrote:
> Hi All,
>
>
>
> I've been trying to find out information on ACL support in Reiserfs, but
> haven't had much luck finding anything but a few exchanges here and there.
> There are numerous capabilities within Reiserfs, which I'd like to take
> advantage of, but this issue of ACL support is only growing.  The problem
> actually consists of trying to store ACLs in a Windows environment.  The
> number of ACEs can be quite sufficient that it can require multiple inodes
> to store everything.  As an example, XFS has a maximum inode size of 2K,
> which is normally fairly sufficient.  However, if I wish to support all of
> the Windows ACL set, then 2K is inadequate and 4K would actually be better.
> Again, I can use multiple inodes, but this has a significant affect on
> performance.  The bottom line is that I love Linux as a server and believe
> I should be able to seamlessly support a Windows client.  I just don't want
> to be as slow as a Windows server.
>
>
>
> With that in mind, can someone give me a quick synopsis of how ACLs are
> handled in Reiserfs v3 and v4?  Also, if there is a url to the information
> I'd appreciate a pointer to it.  Admittedly, I haven't read the man pages.
> So, if it's all there, please forgive me.
>
>
>
> Many thanks,
>
>
>
> Mike

Status of acl's under Linux (start with that, its very informative):
http://www.suse.de/~agruen/acl/linux-acls/

For ReiserfsV3, you have 2 possibilites:
1) use the SuSE distribution, it has ACL's for Reiserfs per default.
2) patch the linux kernel
For kernel 2.6; experimental
  ftp://ftp.suse.com/pub/people/mason/patches/data-logging/experimental/
For kernel 2.4
  http://acl.bestbits.at
  +
  ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea/v2.4/

For the capabilities of Reiser4 read: http://www.namesys.com/

Notes:
* Reiser4 is incompatible with Reiser3.
* I don't know if ReiserfsV3 ACL's will ever be included in the official Linux
kernel. SuSE is supporting this stuff.

-- 
lg, Chris

Re: ACL Support

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Hi All,
|
|
|
| I\x19ve been trying to find out information on ACL support in Reiserfs, but
| haven\x19t had much luck finding anything but a few exchanges here and
| there.  There are numerous capabilities within Reiserfs, which I\x19d like
| to take advantage of, but this issue of ACL support is only growing.
| The problem actually consists of trying to store ACLs in a Windows
| environment.  The number of ACEs can be quite sufficient that it can
| require multiple inodes to store everything.  As an example, XFS has a
| maximum inode size of 2K, which is normally fairly sufficient.  However,
| if I wish to support all of the Windows ACL set, then 2K is inadequate
| and 4K would actually be better.  Again, I can use multiple inodes, but
| this has a significant affect on performance.  The bottom line is that I
| love Linux as a server and believe I should be able to seamlessly
| support a Windows client.  I just don\x19t want to be as slow as a Windows
| server.
|
|
|
| With that in mind, can someone give me a quick synopsis of how ACLs are
| handled in Reiserfs v3 and v4?  Also, if there is a url to the
| information I\x19d appreciate a pointer to it.  Admittedly, I haven\x19t read
| the man pages.  So, if it\x19s all there, please forgive me.

ReiserFS v3 ACLs are implemented as an external patchset, though we've
been trying for some time to convince Hans to accept them. I'm not sure
what you mean by "handled," so I guess I'll just give a rundown of how
the backend works.

ACLs are handled by implementing extended attributes for ReiserFS, and
having the system.posix_acl_access and system.posix_acl_default xattrs
handled specially, and are interpreted by the kernel as part of the
permissions process.

In order to implement extended attributes in a manner that doesn't alter
disk format, my patches add a .reiserfs_priv directory to the root of
the filesystems. xattrs are stored in
.reiserfs/xattrs/<objectid>.<generation number>/<xattr name>. This
directory is hidden from userspace completely when xattrs are enabled,
even as root. When not using my patches, the directory is exposed as a
normal directory and the system administrator is welcome to shoot
himself in the foot. Each file contains a magic, a checksum of the data,
~ and the xattr data itself. When quotas are enabled, extended attributes
are included in the quota usage.

Both access and default ACLs are loaded on demand. This means that for
an access ACL to be loaded, reiserfs_permission requires that
information. If the user owns the file or is root, the ACL won't be
loaded from disk. Once loaded, the entire ACL set for that inode is
cached for the life of the inode. For the default ACL to be loaded, a
file or directory must be created under a directory with a default ACL.
Like access ACLs, once loaded, the default ACL is cached for the life of
the inode.

As far as using them goes, the interface is the standard set of
xattr/acl tools you'd use for any other Linux filesystem that supports them.

Since the xattr implementation uses regular files as the backend, the
number of ACLs per inode is limited only by the maximum size of an
xattr, which is currently limited at the VFS layer to 64k. With 64k to
work with, the on-disk format supports approximately 8k ACLs.

For v2.6, your best bet is to use the patches that are merged against
Chris Mason's data logging patch set. You can get those at Chris's FTP
site[1].

For v2.4, if you're not using a SuSE kernel (which has them already),
you can get the patches from my FTP site[2].

I'm not familiar with the v4 ACL/xattr implementation, so I can't comment.

- -Jeff

[1] ftp://ftp.suse.com/pub/people/mason/patches/data-logging/experimental/
[2] ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea/v2.4/

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbGfnLPWxlyuTD7IRAqovAKCAKpFn93wBVB/Rj9cRg57fXSx7FgCgmRcD
bjKtPjRIwLtxA7naRR/OkMw=
=Dhvk
-----END PGP SIGNATURE-----

RE: ACL Support

[Mike Young]

Wow Jeff!  That's a great explanation and very helpful too.  Can you answer
a couple more questions for me on the v3.x reiserfs?  I'm trying to
understand the limits right now.  For example, how big of a volume can I
support?  How large of a file?  And how many files?

I actually have a problem in that I've got files that are 2TB in size--
nothing bigger, though.  

Thanks,

Mike

-----Original Message-----
From: Jeff Mahoney [mailto:jeffm@suse.com] 
Sent: Thursday, April 01, 2004 11:05 AM
To: Mike Young
Cc: reiserfs-list@namesys.com
Subject: Re: ACL Support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Hi All,
|
|
|
| I\x19ve been trying to find out information on ACL support in Reiserfs, but
| haven\x19t had much luck finding anything but a few exchanges here and
| there.  There are numerous capabilities within Reiserfs, which I\x19d like
| to take advantage of, but this issue of ACL support is only growing.
| The problem actually consists of trying to store ACLs in a Windows
| environment.  The number of ACEs can be quite sufficient that it can
| require multiple inodes to store everything.  As an example, XFS has a
| maximum inode size of 2K, which is normally fairly sufficient.  However,
| if I wish to support all of the Windows ACL set, then 2K is inadequate
| and 4K would actually be better.  Again, I can use multiple inodes, but
| this has a significant affect on performance.  The bottom line is that I
| love Linux as a server and believe I should be able to seamlessly
| support a Windows client.  I just don\x19t want to be as slow as a Windows
| server.
|
|
|
| With that in mind, can someone give me a quick synopsis of how ACLs are
| handled in Reiserfs v3 and v4?  Also, if there is a url to the
| information I\x19d appreciate a pointer to it.  Admittedly, I haven\x19t read
| the man pages.  So, if it\x19s all there, please forgive me.

ReiserFS v3 ACLs are implemented as an external patchset, though we've
been trying for some time to convince Hans to accept them. I'm not sure
what you mean by "handled," so I guess I'll just give a rundown of how
the backend works.

ACLs are handled by implementing extended attributes for ReiserFS, and
having the system.posix_acl_access and system.posix_acl_default xattrs
handled specially, and are interpreted by the kernel as part of the
permissions process.

In order to implement extended attributes in a manner that doesn't alter
disk format, my patches add a .reiserfs_priv directory to the root of
the filesystems. xattrs are stored in
.reiserfs/xattrs/<objectid>.<generation number>/<xattr name>. This
directory is hidden from userspace completely when xattrs are enabled,
even as root. When not using my patches, the directory is exposed as a
normal directory and the system administrator is welcome to shoot
himself in the foot. Each file contains a magic, a checksum of the data,
~ and the xattr data itself. When quotas are enabled, extended attributes
are included in the quota usage.

Both access and default ACLs are loaded on demand. This means that for
an access ACL to be loaded, reiserfs_permission requires that
information. If the user owns the file or is root, the ACL won't be
loaded from disk. Once loaded, the entire ACL set for that inode is
cached for the life of the inode. For the default ACL to be loaded, a
file or directory must be created under a directory with a default ACL.
Like access ACLs, once loaded, the default ACL is cached for the life of
the inode.

As far as using them goes, the interface is the standard set of
xattr/acl tools you'd use for any other Linux filesystem that supports them.

Since the xattr implementation uses regular files as the backend, the
number of ACLs per inode is limited only by the maximum size of an
xattr, which is currently limited at the VFS layer to 64k. With 64k to
work with, the on-disk format supports approximately 8k ACLs.

For v2.6, your best bet is to use the patches that are merged against
Chris Mason's data logging patch set. You can get those at Chris's FTP
site[1].

For v2.4, if you're not using a SuSE kernel (which has them already),
you can get the patches from my FTP site[2].

I'm not familiar with the v4 ACL/xattr implementation, so I can't comment.

- -Jeff

[1] ftp://ftp.suse.com/pub/people/mason/patches/data-logging/experimental/
[2] ftp://ftp.suse.com/pub/people/jeffm/reiserfs/aclea/v2.4/

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbGfnLPWxlyuTD7IRAqovAKCAKpFn93wBVB/Rj9cRg57fXSx7FgCgmRcD
bjKtPjRIwLtxA7naRR/OkMw=
=Dhvk
-----END PGP SIGNATURE-----

Re: ACL Support

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Wow Jeff!  That's a great explanation and very helpful too.  Can you
answer
| a couple more questions for me on the v3.x reiserfs?  I'm trying to
| understand the limits right now.  For example, how big of a volume can I
| support?  How large of a file?  And how many files?
|
| I actually have a problem in that I've got files that are 2TB in size--
| nothing bigger, though.

Mike -

The on-disk format for ReiserFS v3 defines the maximum filesystem size
as 2^32 * blocksize, which is currently limited by the size of a page on
the system. So, 16 TB assuming a 4k blocksize. The maximum file size is
2^61-1bytes, but is obviously limited by the maximum size of the
filesystem. The maximum number of files is 2^32.

If you're using a 2.4 kernel, you're not going to be able to handle that
workload using any filesystem, since block devices are limited to 2^32 *
512 bytes = 2 TB. This, in turn, limits all filesystems to 2 TB in size.

Using the 2.6 kernel, the block device limits have been raised, so
ReiserFS can use its maximum capacity.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbI4vLPWxlyuTD7IRAsaSAJwIN8Vv/W+LVO5xA2muNWhAsuusAACfV2sn
eX23G/LcEyflt0svSywvIUM=
=Bi+O
-----END PGP SIGNATURE-----

RE: ACL Support

[Mike Young]

I should be able to get around the 2TB limit using LBD support on the 2.4
kernel.

Other than that, the 16TB limit shouldn't be a problem either since I can't
get beyond that with the current VFS limit of 32-bit inodes on Xeon
platforms.  With that, I can only go 2^32*4k block size, which is 16TB.

Hmmm.  Reiserfs is looking pretty good for me.

Thanks,

Mike

-----Original Message-----
From: Jeff Mahoney [mailto:jeffm@suse.com] 
Sent: Thursday, April 01, 2004 1:49 PM
To: Mike Young
Cc: reiserfs-list@namesys.com
Subject: Re: ACL Support

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Young wrote:
| Wow Jeff!  That's a great explanation and very helpful too.  Can you
answer
| a couple more questions for me on the v3.x reiserfs?  I'm trying to
| understand the limits right now.  For example, how big of a volume can I
| support?  How large of a file?  And how many files?
|
| I actually have a problem in that I've got files that are 2TB in size--
| nothing bigger, though.

Mike -

The on-disk format for ReiserFS v3 defines the maximum filesystem size
as 2^32 * blocksize, which is currently limited by the size of a page on
the system. So, 16 TB assuming a 4k blocksize. The maximum file size is
2^61-1bytes, but is obviously limited by the maximum size of the
filesystem. The maximum number of files is 2^32.

If you're using a 2.4 kernel, you're not going to be able to handle that
workload using any filesystem, since block devices are limited to 2^32 *
512 bytes = 2 TB. This, in turn, limits all filesystems to 2 TB in size.

Using the 2.6 kernel, the block device limits have been raised, so
ReiserFS can use its maximum capacity.

- -Jeff

- --
Jeff Mahoney
SuSE Labs
jeffm@suse.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAbI4vLPWxlyuTD7IRAsaSAJwIN8Vv/W+LVO5xA2muNWhAsuusAACfV2sn
eX23G/LcEyflt0svSywvIUM=
=Bi+O
-----END PGP SIGNATURE-----

ACL support.

[dE]

Does reiser4 support ACL?

Re: ACL support.

[Edward Shishkin]

On 03/26/2014 06:23 AM, dE wrote:
> Does reiser4 support ACL?

Nope for historical reasons.
I'll provide hints how to implement this, if someone wants..

Edward.

Re: ACL support.

[dE]

On 03/26/14 16:04, Edward Shishkin wrote:
> On 03/26/2014 06:23 AM, dE wrote:
>> Does reiser4 support ACL?
>
> Nope for historical reasons.
> I'll provide hints how to implement this, if someone wants..
>
> Edward.

Thanks for the response.

I was just asking for educational purposes (my home dir recedes on reiser4).

And yes -- I got a major bug to report which cause FF to crash. 
Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.

What do I have to do to report the problem?

Re: ACL support.

[Edward Shishkin]

On 03/26/2014 04:42 PM, dE wrote:
> On 03/26/14 16:04, Edward Shishkin wrote:
>> On 03/26/2014 06:23 AM, dE wrote:
>>> Does reiser4 support ACL?
>>
>> Nope for historical reasons.
>> I'll provide hints how to implement this, if someone wants..
>>
>> Edward.
>
> Thanks for the response.
>
> I was just asking for educational purposes (my home dir recedes on 
> reiser4).
>
> And yes -- I got a major bug to report which cause FF to crash. 
> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>
> What do I have to do to report the problem?

1) "bad" means what?
2) any kernel complaints?
3) results of checking the partition with fsck.reiser4
4) Is it possible to reproduce the problem?

Thanks,
Edward.

Re: ACL support.

[dE]

On 03/26/14 21:31, Edward Shishkin wrote:
> On 03/26/2014 04:42 PM, dE wrote:
>> On 03/26/14 16:04, Edward Shishkin wrote:
>>> On 03/26/2014 06:23 AM, dE wrote:
>>>> Does reiser4 support ACL?
>>>
>>> Nope for historical reasons.
>>> I'll provide hints how to implement this, if someone wants..
>>>
>>> Edward.
>>
>> Thanks for the response.
>>
>> I was just asking for educational purposes (my home dir recedes on 
>> reiser4).
>>
>> And yes -- I got a major bug to report which cause FF to crash. 
>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>
>> What do I have to do to report the problem?
>
> 1) "bad" means what?
> 2) any kernel complaints?
> 3) results of checking the partition with fsck.reiser4
> 4) Is it possible to reproduce the problem?
>
> Thanks,
> Edward.

I started having problems with FF which was diagnosed to contents of 
~/.firefox. So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
~/.firefox to solve the problem.

So I still have ~/.firefox_bad; this problem occurred twice, and I have 
both of the ~/.firefox_bad

Yes -- the kernel showed a backtrace from some reiser4 sources.

fsck.reiser4 was done -- nothing was wrong.

Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.

Re: ACL support.

[Edward Shishkin]

On 03/26/2014 05:44 PM, dE wrote:
> On 03/26/14 21:31, Edward Shishkin wrote:
>> On 03/26/2014 04:42 PM, dE wrote:
>>> On 03/26/14 16:04, Edward Shishkin wrote:
>>>> On 03/26/2014 06:23 AM, dE wrote:
>>>>> Does reiser4 support ACL?
>>>>
>>>> Nope for historical reasons.
>>>> I'll provide hints how to implement this, if someone wants..
>>>>
>>>> Edward.
>>>
>>> Thanks for the response.
>>>
>>> I was just asking for educational purposes (my home dir recedes on 
>>> reiser4).
>>>
>>> And yes -- I got a major bug to report which cause FF to crash. 
>>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>>
>>> What do I have to do to report the problem?
>>
>> 1) "bad" means what?
>> 2) any kernel complaints?
>> 3) results of checking the partition with fsck.reiser4
>> 4) Is it possible to reproduce the problem?
>>
>> Thanks,
>> Edward.
>
> I started having problems with FF which was diagnosed to contents of 
> ~/.firefox.

Which kernel version?
Do you use the new reiser4 transaction models announced not so long ago?

> So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
> ~/.firefox to solve the problem.
>
> So I still have ~/.firefox_bad; this problem occurred twice, and I 
> have both of the ~/.firefox_bad
>
> Yes -- the kernel showed a backtrace from some reiser4 sources.

Could you send it, if possible?

Thanks,
Edward.

>
> fsck.reiser4 was done -- nothing was wrong.
>
> Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.

Re: ACL support.

[dE]

On 03/26/14 22:34, Edward Shishkin wrote:
> On 03/26/2014 05:44 PM, dE wrote:
>> On 03/26/14 21:31, Edward Shishkin wrote:
>>> On 03/26/2014 04:42 PM, dE wrote:
>>>> On 03/26/14 16:04, Edward Shishkin wrote:
>>>>> On 03/26/2014 06:23 AM, dE wrote:
>>>>>> Does reiser4 support ACL?
>>>>>
>>>>> Nope for historical reasons.
>>>>> I'll provide hints how to implement this, if someone wants..
>>>>>
>>>>> Edward.
>>>>
>>>> Thanks for the response.
>>>>
>>>> I was just asking for educational purposes (my home dir recedes on 
>>>> reiser4).
>>>>
>>>> And yes -- I got a major bug to report which cause FF to crash. 
>>>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>>>
>>>> What do I have to do to report the problem?
>>>
>>> 1) "bad" means what?
>>> 2) any kernel complaints?
>>> 3) results of checking the partition with fsck.reiser4
>>> 4) Is it possible to reproduce the problem?
>>>
>>> Thanks,
>>> Edward.
>>
>> I started having problems with FF which was diagnosed to contents of 
>> ~/.firefox.
>
> Which kernel version?
> Do you use the new reiser4 transaction models announced not so long ago?
>
>> So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
>> ~/.firefox to solve the problem.
>>
>> So I still have ~/.firefox_bad; this problem occurred twice, and I 
>> have both of the ~/.firefox_bad
>>
>> Yes -- the kernel showed a backtrace from some reiser4 sources.
>
> Could you send it, if possible?
>
> Thanks,
> Edward.
>
>>
>> fsck.reiser4 was done -- nothing was wrong.
>>
>> Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.
>

Kernel is 3.8.5. So no, it's an old one.

Yes, I'll send the bt. Wait.

Re: ACL support.

[dE]

On 03/27/14 20:51, dE wrote:
> On 03/26/14 22:34, Edward Shishkin wrote:
>> On 03/26/2014 05:44 PM, dE wrote:
>>> On 03/26/14 21:31, Edward Shishkin wrote:
>>>> On 03/26/2014 04:42 PM, dE wrote:
>>>>> On 03/26/14 16:04, Edward Shishkin wrote:
>>>>>> On 03/26/2014 06:23 AM, dE wrote:
>>>>>>> Does reiser4 support ACL?
>>>>>>
>>>>>> Nope for historical reasons.
>>>>>> I'll provide hints how to implement this, if someone wants..
>>>>>>
>>>>>> Edward.
>>>>>
>>>>> Thanks for the response.
>>>>>
>>>>> I was just asking for educational purposes (my home dir recedes on 
>>>>> reiser4).
>>>>>
>>>>> And yes -- I got a major bug to report which cause FF to crash. 
>>>>> Duplicating ~/.firefox solved the problem. I've the bad ~/.firefox.
>>>>>
>>>>> What do I have to do to report the problem?
>>>>
>>>> 1) "bad" means what?
>>>> 2) any kernel complaints?
>>>> 3) results of checking the partition with fsck.reiser4
>>>> 4) Is it possible to reproduce the problem?
>>>>
>>>> Thanks,
>>>> Edward.
>>>
>>> I started having problems with FF which was diagnosed to contents of 
>>> ~/.firefox.
>>
>> Which kernel version?
>> Do you use the new reiser4 transaction models announced not so long ago?
>>
>>> So renamed it to ~/.firefox_bad and copied ~/.firefox_bad to 
>>> ~/.firefox to solve the problem.
>>>
>>> So I still have ~/.firefox_bad; this problem occurred twice, and I 
>>> have both of the ~/.firefox_bad
>>>
>>> Yes -- the kernel showed a backtrace from some reiser4 sources.
>>
>> Could you send it, if possible?
>>
>> Thanks,
>> Edward.
>>
>>>
>>> fsck.reiser4 was done -- nothing was wrong.
>>>
>>> Yes -- I have the ~/.firefox_bad just for the purpose of bug reporting.
>>
>
> Kernel is 3.8.5. So no, it's an old one.
>
> Yes, I'll send the bt. Wait.

Ok, I've realized the mailing list software rejected the mail silently.

Re: ACL support.

[Edward Shishkin]

On 04/08/2014 08:28 PM, Daniel Horne wrote:
> On 26 March 2014 10:34, Edward Shishkin <edward.shishkin@gmail.com
> <mailto:edward.shishkin@gmail.com>> wrote:
>
>     On 03/26/2014 06:23 AM, dE wrote:
>
>         Does reiser4 support ACL?
>
>
>     Nope for historical reasons.
>     I'll provide hints how to implement this, if someone wants..
>
>
> I occasionally have a look at making an XATTR implementation before
> getting sidetracked.
>
> There's a couple of points I'm not quite decided on:
>
> Whether to make a generic xattr stat_data plugin and use it to store all
> different types of attribute, or make different plugins for ACL, SElinux
> contexts, and user xattrs.
>
> You've previously stated that stat_data plugins are limited to 4k. This
> should be fine for selinux contexts and all but pathologically long
> access control lists, I'm not sure about the use of user xattrs. Would
> making separate stat_data plugins give separate 4k limits to each type
> of attribute, or is that all-inclusive?
>


Actually stat-data is an on-disk container of inode fields. That said, I 
would prefer to store xattrs in special items, which are different from 
stat-data (one such item per a pair (xattr_name, xattr_value)).


> There's also the matter of choosing an on-disk format. A simple list
> format, perhaps? Lookup would be O(n), but given the small amount of
> data we're expecting to store there, that may be OK.

I suggest that we use the following format for the xattr items.

The key of the item associated with the pair (xattr_name, xattr_value) 
is [base_key, offset], where base_key is calculated by build_xattr_key()
(not yet implemented). This function does mostly the same as 
build_sd_key(). The difference is that build_xattr_key() installs
a special reserved (and currently not used) minor locality 
KEY_ATTR_NAME_MINOR (see key.h for the definition).

64-bit key offset is composed of 32-bit major_offset and 32-bit minor 
offset. Major offset is a 32-hash of the xattr_name. Minor offset is the 
number of the collision in the chronology ordering.

Format of the item body is the following:
. size-of-xattr_name (16 bit)
. xattr_name;
. xattr_value

So getxattr(2) is resolved to the following actions:

. build base_key for the xattr_name;
. set major offset as hash(xattr_name);
. linear search for precise xattr_name among all items with the same 
[key_base, major_offset].
. return respective xattr_value (or NOT_FOUND).

setxattr(2) is resolved to the following actions:

. compose the item body in accordance with the format above;
. build base_key for xattr_name;
. set the major offset, i.e. hash(xattr_name);
. search for the xattr_name among all items with the same [base_key, 
major_offset];
. update the item body, or (depending on the flags) return EEXIST, if 
the item with xattr_name was found;
. set the respective minor_offset by the search results, if the item 
with xattr_name was not found;
. insert the new item with the [base_key, offset] to the current 
position in the tree.

For simplicity and performance reasons let's assume that xattr items are 
solid. That said, any xattr item contains exactly one unit. In 
particular, it means that sizeof(xattr_name + xattr_value) can not 
exceed 4096 - (sizeof(node_header) + sizeof(item_header)). Let's 
implement xattrs support with such restrictions for now. Also, don't 
update minor offsets of colliding items when removing xattr: I don't 
think that we'll exceed the limit for the number of collisions (2^32)
in the foreseeable future.

Makes sense?
Let me know if any problems..

Thanks,
Edward.