On Sun, 18 May 2003, Andreas Dilger wrote:
> On May 18, 2003 17:04 +0000, Alex Tomas wrote:
> > this patch implements possibility to store EA into inode body
> > which may be larger 128 bytes in 2.5 kernel.
>
> What Alex didn't mention was the reason why we developed this patch in the
> first place - speed.
The patch looks very good. A few issues come to mind:
- What's the status of the other fixed fields in the large inodes? Is
there agreement on adding exactly the fields in the patch?
- A common operation is to change an attribute's value without changing
the value's length. The current code does not optimize this case, but
it should. The patch makes this optimization a little harder.
- struct ext3_xattr_entry makes little sense in an inode. The
e_value_block and e_hash fields should go away. The e_value_size
field could be shrunk from 4 to 2 bytes. This would save 10 bytes per
attribute. The code wouldn't become a lot more messy from that.
- In-inode EA support should be configurable. I would like to choose
whether I want this feature at compile time, with as few #ifdef's as
possible.
> Storing EAs in external blocks is slow, and if you
> have a lot of inodes with external EAs it is fatal, as the EA blocks consume
> so much RAM that they force all of the inode/directory data out of cache.
The current implementation is not suitable for applications which store
unique EAs for very many inodes. Storing the EAs in the inodes is much
better, but increasing the inode size also costs space.
> Some benchmarks (from Alex):
> > environment for old EA: just mkfs'ed EXT3, inode size 128, 33000 files
> > environment for fast EA: just mkfs'ed EXT3, inode size 256, 33000 files
> >
> > old EA fast EA
> > add attributes 2m35.241s 1m4.151s (+142%)
> > dump attributes 0m28.716s 0m13.466s (+113%)
> > change attributes 2m42.108s 1m4.413s (+153%)
> > remove attributes 1m15.373s 1m3.909s (+19%)
Nice. That's probably with unique attributes per inode.
> Some minor improvements could be made, such as not storing user EAs inside
> the inode if there are system EAs that could be stored there.
I don't know which strategy will be best here. We don't have to solve this
problem now, though.
By the way, you will likely also need dynamically allocated inodes, right?
What's the status here?
Cheers,
Andreas.
------------------------------------------------------------------
Andreas Gruenbacher SuSE Linux AG
mailto:agruen@suse.de Deutschherrnstr. 15-19
http://www.suse.de/ D-90429 Nuernberg, Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri May 23 2003 - 22:00:46 EST