My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 46: resolve ext2 dependency avoiding ohsm_get_tier call
1 person starred this issue and may be notified of changes. Back to list
 
Project Member Reported by imreckless@gmail.com, Jan 28, 2009
At the time of allocation, in namei.c when new inode is created,
ohsm_get_tier qualifies the inode for a policy.
This function is currently in ohsm.c which is to be added to ext2.

We have to resolve the interdependency.


Jan 28, 2009
Project Member #1 sandeepksinha
The major problem with such an implementation would be that it would cause things to
break when we move to ext3/4.

So, looks like will lead to a design change.

Vineet/RKS can you take this at the highest priority and get this issue resolved asap.
 
Labels: Component-Logic Usability Maintainability
Jan 29, 2009
Project Member #2 imreckless@gmail.com
In that case we will have to move the allocation structures in ext2 itself,
and even all the functions that qualify inode for allocation. 
We will create a function in ext2 itself, this function will
fill all the structures and we have to call this function from ohsm_admin.
Rishi can you comment on this.
Jan 29, 2009
Project Member #3 sandeepksinha
Well, Looks like moving this allocation qualifier function, and
ohsm_ext2_new blocks in ohsm.c will be a final option.

Well, move all the ohsm specific variables and functions in ohsm.c .
update the makefile
and create a patch.
Check if it works.
Jan 29, 2009
#4 postri...@gmail.com
in any case this will create name space problem if ext3/4 is also there

we can solve the namespace problem by adding "ext2_" to it but then we will have to
it for "ext3_" "ext4_" as well

But that will be a better solution as the admin will have different policies for
different file systems mounted at different location. For differnent policies we need
to have different pointers.

Once I and SKS had a discussion about using function pointers

the funda was
-> get_tier_name will be called by function pointers and not by function name
-> when ohsm_admin is inserted or started or OHSM_ENABLED flag is up it will change
the pointers to the functions defined in the admin.
-> earlier the function pointer will be pointing to and empty defination which will
just return 0 when ever called 
-> after changing the pointers it will act with the policies


Jan 29, 2009
#5 postri...@gmail.com
for ext3 / ext4 or other ext2 also mounted at diffent points

A new stucture can be made 
struct new_structure
{
char mountpoint[];
/*or here can be pointer to vfsmount structure*/
alloc_policy *
reloc_policy *
tier_device *
}


so when ever you want the policy regarding any dentry i will take out the mountpoint 
or the vfsmount structure from the dentry

match it with the above written structure ( simple linear search)

and will give the tier value according to the mount point



Jan 29, 2009
Project Member #6 checkout...@gmail.com
> Well, Looks like moving this allocation qualifier function, and
> ohsm_ext2_new blocks in ohsm.c will be a final option.

Moving ohsm_ext2_new_blocks to ohsm.c would cause a problem since many of the
functions used in ohsm_ext2_new_blocks are static and in-line.


Jan 29, 2009
Project Member #7 imreckless@gmail.com
That is a good solution, if we are allowed to add these structures in ext2,
and even all the qualification functions.

Jan 29, 2009
Project Member #8 sandeepksinha
See the justification that I have to it is that, 
we are changing the behavior of the file creation, which is a property of the FS.
So, anyone who is using the OHSM cannot expect the file system to be free of changes.
Either we do it for ext2 provides us with API.

If you guys know I am trying to get the ioctl in the ext2/3 for the same.
I am in touch with Akira/tytso.
Jan 29, 2009
#9 postri...@gmail.com
My question here is

if any user has a mounted file system in /mnt with allocation policy A reloaction
policy R and tier device info as T and he has OHSM_ENABLED

If he wants to mount another FS at /media with allocation policy as XA relocation
policy as XR and tier info as XT and he wants to enable OHSM

What will be the behaviour of the OHSM

As of now the user can do this but then OHSM will not work for /mnt and MAY even
crash(unlikely)

But We need to decide What SHOULD be the behaviour of OHSM ?
answers-> we do not support this as per now but will be done in 2.0
->we support it in 1.0 itself
Jan 29, 2009
Project Member #10 sandeepksinha
That actually makes sense and a good answer to it as well.
This is a restriction for now.
And we will be we providing with this feature in our next major release and not in
the minor releases.
Thats OHSM 2.0.0
Jan 29, 2009
Project Member #11 sandeepksinha
Whenever you go to enable or apply policies, you just check if OHSM is already
enabled. If it is enabled. we will return with error.

And ya, if other ext2 file system will be mounted, it will also get affected by OHSM
behavior,
but thats accepted. And we have this in the limitations bOOk :P
Jan 30, 2009
#12 postri...@gmail.com
(No comment was entered for this change.)
Status: Todo-Later
Jan 30, 2009
Project Member #13 imreckless@gmail.com
We hav added ohsm.c in ext2.
Moving ahead with this change.

Jan 31, 2009
Project Member #14 imreckless@gmail.com
Considering this issue done for OHSM 1.0
Status: Fixed

Powered by Google Project Hosting