Re: [Fwd: [Fwd: Re: Xattrs in reiser4 and Google Summer of Code]]

Re: [Fwd: [Fwd: Re: Xattrs in reiser4 and Google Summer of Code]]

[Edward Shishkin]

Daniel Horne wrote:
> Hi..

Hello,
Let's cc the list for technical talks, ok?

>
> Thanks for this. I had a brief look at the stat-data plugin, but I
> suspect it's not *quite* general enough to implement the full range of
> xattrs. In particular, you mention below that a stat-data item must be
> under 4000 bytes, and that each stat-data plugin should have its own
> behaviour written for it for reiser4tools.
>

I wanted something like a review to estimate a high boundary for total
amount
of space that can be occupied by pairs (key: value) in one file for
efficient work
of important xattrs applications like Selinux.

> With Xattrs you can pretty much set arbitrary key:value pairs, which
> means that writing a stat-data plugin for each of the possible xattr
> keys is completely impractical.

We don't need a separate stat-data plugin for _each_ possible xattr key:
The common sd-plugin that can scan nodes in order to gather scattered
stat-data of arbitrary length will cover _all_ cases.

> Also, it means that the if expressed as a list, the possible length of
> the xattrs on an inode are potentially a lot longer than 4000.

Can you say more about this?
Do you know an application that requires xattrs of length longer then
4000 bytes?

>
> So, the temptation is to have something similar to the file plugin for
> individual xattrs, with the xattr functions on a vfs file acting like
> a directory of xattr-files. There'd be a large number of small objects
> in the tree, of course, but that's a situation I understand R4 handles
> well..
>
> So, what do you think?

Let's forget about file-as-dir stuff. All what we need is a new file plugin
with non-NULL methods, responsible for work with xattrs , and (maybe)
a new stat-data plugin, which can handle stat-data items of arbitrary
length.

Thanks,
Edward.

Re: [Fwd: [Fwd: Re: Xattrs in reiser4 and Google Summer of Code]]

[Daniel Horne]

2008/12/17 Edward Shishkin <edward.shishkin@gmail.com>


    Can you say more about this?
    Do you know an application that requires xattrs of length longer then
    4000 bytes?


User xattrs. What I'm thinking is that if you can set arbitrary
key:value pairs (which, of course, you can - through setfattr) the
"high bound"  number of xattrs per inode, and therefore total data
stored is pretty much unlimited.


    >
    > So, the temptation is to have something similar to the file plugin for
    > individual xattrs, with the xattr functions on a vfs file acting like
    > a directory of xattr-files. There'd be a large number of small objects
    > in the tree, of course, but that's a situation I understand R4 handles
    > well..
    >
    > So, what do you think?

    Let's forget about file-as-dir stuff. All what we need is a new file plugin
    with non-NULL methods, responsible for work with xattrs , and (maybe)
    a new stat-data plugin, which can handle stat-data items of arbitrary
    length.


Agreed.

--
DH

Re: Xattrs in reiser4...

[Edward Shishkin]

Daniel Horne wrote:
> 2008/12/17 Edward Shishkin <edward.shishkin@gmail.com>
>
>
>     Can you say more about this?
>     Do you know an application that requires xattrs of length longer then
>     4000 bytes?
>
>
> User xattrs. What I'm thinking is that if you can set arbitrary
> key:value pairs (which, of course, you can - through setfattr) the
> "high bound"  number of xattrs per inode, and therefore total data
> stored is pretty much unlimited.
>   

Yes, there is no doubt, that somebody will want to shove
a gigabyte of information by using setxattr(2) :)
The question is "whether it is really needed?"

Well, I think, we can implement xattrs with the mentioned
limit for now. If it won't be enough for serious applications
(it will be clear before xattrs release), then we'll think about
new stat-data plugin.

Edward.

>
>     >
>     > So, the temptation is to have something similar to the file plugin for
>     > individual xattrs, with the xattr functions on a vfs file acting like
>     > a directory of xattr-files. There'd be a large number of small objects
>     > in the tree, of course, but that's a situation I understand R4 handles
>     > well..
>     >
>     > So, what do you think?
>
>     Let's forget about file-as-dir stuff. All what we need is a new file plugin
>     with non-NULL methods, responsible for work with xattrs , and (maybe)
>     a new stat-data plugin, which can handle stat-data items of arbitrary
>     length.
>
>
> Agreed.
>
> --
> DH
>
>