| Issue 15: | "ext2yaan" the block allocation test phase 1 | |
| 1 person starred this issue and may be notified of changes. | Back to list |
|
We shall now proceed with the testing of block allocation for OHSM. We use a 1gb disk, that is a pen drive for testing. We will create an ohsm_alloc_inode function, it will be similar to ext2_alloc_inode() function just a few checks will be performed. (functions name may differ) We will qualify a block group by checking the policy and mapping table and then allocate inode for it. Similarly we will check for data blocks. Test phase 1 : inode allocation Work assigned to individuals. VA and SS : Device mapper table. TL : File system meta data, for this test , file name. RKS : ohsm inode allocation function. After successful test we will proceed to phase 2 that is data block allocation. All the best.
Dec 22, 2008
Project Member
#1
sandeepksinha
Cc:
checkout.vineet postrishi rohitvashist2kk3 imreckless bharati.alatgi
Dec 22, 2008
Well phase one of the test is successful. As some modules are not ready we started with certain assumptions, as every experiment takes into consideration. Like we have chosen a block group range to allocate inodes. The allocation of inodes were restricted to the specified BG range successfully. Few more optimizations are to be done as find_group_orlov() is a mess, so we have to apply some more optimizations, as allocation of inodes for directories is being clustered towards the start of BG range.
Labels:
Type-Enhancement
Dec 22, 2008
I could trace out the file name hence the file type from the kernel sapce. Now what remains is to match the file type and the respective tiers and hence the block groups for that file. The entire path of the file has also being traced out but the fields before the mount point are missing. I will find out the reason for it.
Dec 22, 2008
You don't have the full path of any file. It will always be relative to the mountpoint. I am sure this stupidity of finding the complete path can be done only by Rishi. Why the hell do you require the full path name. You dont need it at all. Anything that you specify will always be specific to the mount point. You just know how to waste time. Seriously. RKS what is this ??? This is going again and again. BTW, just FYI, if you want complete path, just pre-append the mount point to the path which is relative to mount point. It will give you a absolute path.
Dec 23, 2008
I was doing it so that we can work according to the "directory " policy but as we have decided against that policy for the time being it is fine. I have kept the module for future reference
Dec 25, 2008
well my assigned work of device mapper is complete and it can now support the "ext2yaan" the block allocation test phase I am providing with the range of block group which would help in both inode and block allocation And I want to add that in some test for inode allocation are still left. The work done so far checks for only single range of blocks group existing in a tier. The work that is left is to check for a tier which consist of multiple ranges of block groups.
Status:
In-progress
Dec 26, 2008
well the phase 2 of "ext2yaan" test is successful. we are now able to restrict data blocks to particular block groups.so allocation can now be carried out on desired block group range for both inode and data blocks. we are to start the test phase 3 The work left is 1 --> To check for a tier which consist of multiple ranges of block groups. 2 --> To allow file to span on a lower priority tier if space in higher priority tier is finished.
Dec 28, 2008
Phase one is complete, so i am closing this issue.
Status:
Done
|
||||||||||