> > With the registration API modules doing HSM/LSM/... can
> just register
> > handlers
> > without having to modify the file system code. Otherwise we
> would have to
> > hand code additional hooks for independently loadable modules.
>
> a) if the HSM/whatever is so standalone that it should patch ext2 code
> it is truely generic and thus above the filesystem.
> b) you don;t even export the register/unregister to modules,
> not mention
> other ext2/ext3 core functionality that it would need.
> c) looks at the 'would' there is no such code currently and
> if it gets
> a real consern it still could be added. Don't bloat the kernel
> more than you really need to..
Actually we are currently developing HSM application that stacks on top of
standard file system (ext3 and XFS today) and we are using EA to store HSM
specific information with each inode. However, we are not using registration
API, but rather store this in user EA (even if we don't like some
limitations of user EA), because registration API is not exported and
registration API is per-FS and not generic. This would mean that we would
need to have handlers defined for each supported filesystem (ext3 and XFS
today, reiserfs and JFS in near future). As we use user EA, we just call VFS
EA operations of the bottom FS (ext3 or XFS or any other FS that supports
EA).
I agree with your point that this interfaces needs to be exported, but I
would also prefer if they would be generic in terms of being able to
register the same EA handler for each FS supporting EAs (an allowing
extensions/registrations).
I think that we could also then have only single ACL code for both ext2 and
ext3 - currently ACL patch adds similar (same?) code to both ext2 and ext3
and this code could be shared for sure.
Regards,
Luka
On Wed, Oct 09, 2002 at 10:53:47AM +0200, Luka Renko wrote:
> Actually we are currently developing HSM application that stacks on top of
> standard file system (ext3 and XFS today) and we are using EA to store HSM
> specific information with each inode. However, we are not using registration
> API, but rather store this in user EA (even if we don't like some
> limitations of user EA), because registration API is not exported and
> registration API is per-FS and not generic. This would mean that we would
> need to have handlers defined for each supported filesystem (ext3 and XFS
> today, reiserfs and JFS in near future). As we use user EA, we just call VFS
> EA operations of the bottom FS (ext3 or XFS or any other FS that supports
> EA).
Yupp, that's exactly what I meant.
> I think that we could also then have only single ACL code for both ext2 and
> ext3 - currently ACL patch adds similar (same?) code to both ext2 and ext3
> and this code could be shared for sure.
And JFS and reiserfs. Yes, this code should be in a library, but e.g.
XFS (different ondisk format) or NFSv4/NTFS/whatever need very different
ACL rountines. You can't easily plug the handler into different filesystems
due to very different implementations below the VFS level.
BTW, do you have a pointer to your DSM system? I'l like to look at something
less broken them dmapi..