I don't know if this has been already discussed on the list before.
Is it wise enough to abstract away the usage of blocks for storing
extended attributes? I mean can the code - of using filesystem
blocks, putting headers and all data in place within the blocks,
managing the block boundaries, padding ... - be taken away from within
the xattr code. I know xattr is filesystem specific, but if most of
filesystems are using blocks not associated with any inode to store
xattr-specifc information it could well be taken to a different layer
- just like mbcache. Almost only ext2/3 uses mbcache - and that too
only for xattr - but it is implemented at an abstract level.
Not only this would add to the modularization, this can help other
filesystems if they want to use filesystem blocks. Like if one wishes
to implement distributed filesystem, he may prefer to store the FS
metadata in blocks rather than in files. Is it advisible for him to
redo the code, which is very beautifully written in ext2/3 ? I think
not.
AG
On Fri, Sep 03, 2004 at 12:59:42AM +0530, Amit Gud wrote:
> Is it wise enough to abstract away the usage of blocks for storing
> extended attributes?
No. Some fs' will store xattr data in the inodes if it fits.
--cw
>
> > Is it wise enough to abstract away the usage of blocks for storing
> > extended attributes?
>
> No. Some fs' will store xattr data in the inodes if it fits.
>
First up, why is mbcache code is written at VFS layer than being
filesystem specific? Neccessarily to take away the coding overheads of
maintaining block cache that any filesystem uses, even though given
that only ext2 and ext3 uses it. It facilitates code reuse.
Now if we are making reuse of the code to manage block cache, why
can't we make use of the code of allocating blocks, storing the stuff
and other intricacies of block boundary management by writing the code
at another layer, which other fs' can use readiliy including ext2
ext3?
This is advantageous for new filesystems or new fs features which may
use disk blocks not assiciated with any inode for some purpose. Right
now if I'm to do, I'II have to rewrite the code of whole block
management. But I can avail the block cache functions of mbcache.
Like I said, forget what fs does what to store its xattr, ext2/3 is
just an example which uses blocks to store them. What I'm pointing to
is generic interface to the block management code. If the block
management code is written with a generic interface, like mbcache, it
would be very helpful for the future filesystems or for new features
in the exiting fs'.
AG
On Fri, Sep 03, 2004 at 10:26:23AM +0530, Amit Gud wrote:
> >
> > > Is it wise enough to abstract away the usage of blocks for storing
> > > extended attributes?
> >
> > No. Some fs' will store xattr data in the inodes if it fits.
> >
>
> First up, why is mbcache code is written at VFS layer than being
> filesystem specific? Neccessarily to take away the coding overheads of
> maintaining block cache that any filesystem uses, even though given
> that only ext2 and ext3 uses it. It facilitates code reuse.
It is not written at the VFS level. It's a library ontop of the buffercache
than can be reused by filesystems.
> > First up, why is mbcache code is written at VFS layer than being
> > filesystem specific? Neccessarily to take away the coding overheads of
> > maintaining block cache that any filesystem uses, even though given
> > that only ext2 and ext3 uses it. It facilitates code reuse.
>
> It is not written at the VFS level. It's a library ontop of the buffercache
> than can be reused by filesystems.
>
Nice to know this. But intent of my mail is not affected by this in a major way.
AG