On Feb 24, 2008 17:20 +0530, Kalpak Shah wrote:
> On Thu, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
> > Mark Shellenbaum wrote:
> > > General comment:
> > >
> > > I'm not sure we should be using nvlists to store these attributes.
> > > While it will be quick to implement, I'm concerned ab
On Thu, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
> Mark Shellenbaum wrote:
> > General comment:
> >
> > I'm not sure we should be using nvlists to store these attributes.
> > While it will be quick to implement, I'm concerned about the constant
> > packing/unpacking and searching linked
On Feb 11, 2008, at 8:42 PM, Andreas Dilger wrote:
> On Feb 09, 2008 08:10 -0700, Mark Maybee wrote:
>>> Hi Matthew,
>>> There's also the question of the attribute size limit.. from
>>> conversations
>>> I had with Andreas, I got the feeling that the Lustre layout
>>> information
>>> could b
On Feb 09, 2008 08:10 -0700, Mark Maybee wrote:
>> Hi Matthew,
>> There's also the question of the attribute size limit.. from conversations
>> I had with Andreas, I got the feeling that the Lustre layout information
>> could be quite big when a file is striped through all OSTs, and I would
>>
To put the document in a better perspective:
The extended attributes (EAs), as we(Lustre) see, are the lighter weighted
extended
attributes which are user defined and user can be Beagle, Metatracker, Lustre
etc.
Lustre has been using the extended attributes http://acl.bestbits.at/about.html
wh
Ricardo M. Correia wrote:
> Hi Matthew,
>
> On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
>> on disk:
>> header:
>> struct sa_phys {
>> uint16_t sa_numattrs;
>> struct {
>> uint16_t sa_type; /* enum sssa_type */
>> uint16_t sa_leng
Hi Matthew,
On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
> on disk:
> header:
> struct sa_phys {
> uint16_t sa_numattrs;
> struct {
> uint16_t sa_type; /* enum sssa_type */
> uint16_t sa_length; /* in sainfo[sa_type] chunks */
On Qui, 2008-02-07 at 22:51 -0700, Neil Perrin wrote:
> I believe when a prototype using 1K dnodes was tested it showed an
> unacceptable (30%?) hit on some benchmarks. So if can possibly
> avoid increasing the dnode size (by default) then we should do so.
Hmm, interesting..
Do you know the rea
On Feb 08, 2008 18:09 +, Ricardo Correia wrote:
> On Qui, 2008-02-07 at 22:51 -0700, Neil Perrin wrote:
> > I believe when a prototype using 1K dnodes was tested it showed an
> > unacceptable (30%?) hit on some benchmarks. So if can possibly
> > avoid increasing the dnode size (by default) the
On Feb 07, 2008 17:14 +, Ricardo Correia wrote:
> On Qui, 2008-02-07 at 09:44 -0700, Mark Shellenbaum wrote:
> > Section 2.2.4
> >
> > Not sure what you mean by storing all xattrs in a single object? Are you
> > saying all of the Lustre attributes would be stored in a single Solaris
> > ext
Andreas Dilger wrote:
> On Feb 07, 2008 17:14 +, Ricardo Correia wrote:
>> On Qui, 2008-02-07 at 09:44 -0700, Mark Shellenbaum wrote:
>>> Section 2.2.4
>>>
>>> Not sure what you mean by storing all xattrs in a single object? Are you
>>> saying all of the Lustre attributes would be stored in a
Ricardo M. Correia wrote:
> On Qui, 2008-02-07 at 22:51 -0700, Neil Perrin wrote:
>> I believe when a prototype using 1K dnodes was tested it showed an
>> unacceptable (30%?) hit on some benchmarks. So if can possibly
>> avoid increasing the dnode size (by default) then we should do so.
>
> Hmm, i
Andreas Dilger wrote:
> On Feb 07, 2008 22:51 -0700, Neil Perrin wrote:
>>> It seems to me that the usefulness of extended attributes is to
>>> efficiently store small amounts of information associated with a file,
>>> and I think these would make more sense to be in the dnode (possibly
>>> m
On Feb 07, 2008 22:51 -0700, Neil Perrin wrote:
> > It seems to me that the usefulness of extended attributes is to
> > efficiently store small amounts of information associated with a file,
> > and I think these would make more sense to be in the dnode (possibly
> > making it 1K by default) or
On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
> First, note that the problem is quite constrained:
>
> There are a fixed number of attribute names (for any given software version)
> since these are interpreted system attributes. Therefore the attribute names
> can be a small number,
Ricardo M. Correia wrote:
>
> On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
>> First, note that the problem is quite constrained:
>>
>> There are a fixed number of attribute names (for any given software version)
>> since these are interpreted system attributes. Therefore the attribu
Hi,
With reference to my previous mail ([zfs-code] Nvpair for storing EAs
in dnode) which had expressed our intent to use libnvpair for EAs in
dnode. I am now sending a high level design document for the same.
Any suggestions/comments are most welcome.
Thanks & Regards,
Girish
---
On Qui, 2008-02-07 at 10:29 -0700, Mark Shellenbaum wrote:
> Ok, but we don't know how many attributes future consumers may want to
> store. I hope it will be small, but I wouldn't want to paint ourselves
> in a corner and then wish we had done it a different way.
That would be a matter of f
On Qui, 2008-02-07 at 17:14 +, Ricardo M. Correia wrote:
> > Not sure what you mean by storing all xattrs in a single object? Are you
> > saying all of the Lustre attributes would be stored in a single Solaris
> > extended attribute file?
>
>
> Yes. The benefit of this approach is that it
On Qui, 2008-02-07 at 09:44 -0700, Mark Shellenbaum wrote:
> I'm not sure we should be using nvlists to store these attributes.
> While it will be quick to implement, I'm concerned about the constant
> packing/unpacking and searching linked lists in the nvlist code.
That is also one of things
Ricardo M. Correia wrote:
>
> On Qui, 2008-02-07 at 12:48 -0800, Matthew Ahrens wrote:
>> First, note that the problem is quite constrained:
>>
>> There are a fixed number of attribute names (for any given software version)
>> since these are interpreted system attributes. Therefore the attribute
Matthew Ahrens wrote:
> Mark Shellenbaum wrote:
>> Girish Shilamkar wrote:
>>> Hi,
>>> With reference to my previous mail ([zfs-code] Nvpair for storing EAs
>>> in dnode) which had expressed our intent to use libnvpair for EAs in
>>> dnode. I am now sending a high level design document for the
Mark Shellenbaum wrote:
> Girish Shilamkar wrote:
>> Hi,
>> With reference to my previous mail ([zfs-code] Nvpair for storing EAs
>> in dnode) which had expressed our intent to use libnvpair for EAs in
>> dnode. I am now sending a high level design document for the same.
>>
>> Any suggestions/
Ricardo M. Correia wrote:
>
> On Qui, 2008-02-07 at 09:44 -0700, Mark Shellenbaum wrote:
>> I'm not sure we should be using nvlists to store these attributes.
>> While it will be quick to implement, I'm concerned about the constant
>> packing/unpacking and searching linked lists in the nvlist co
Girish Shilamkar wrote:
> Hi,
> With reference to my previous mail ([zfs-code] Nvpair for storing EAs
> in dnode) which had expressed our intent to use libnvpair for EAs in
> dnode. I am now sending a high level design document for the same.
>
> Any suggestions/comments are most welcome.
>
25 matches
Mail list logo
