<%BANNER%>

Design and Implementation of GridOS: Operating System Services for Grid Architectures

xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110112_AAAABG INGEST_TIME 2011-01-12T23:59:07Z PACKAGE UFE0002826_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 32594 DFID F20110112_AAAIRZ ORIGIN DEPOSITOR PATH padala_p_Page_19thm.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
c55f9f284490b51fdedbcfcc31c5909c
SHA-1
ef79b737e689b6e5343c4fedaf746264f33ba6e6
25271604 F20110112_AAAIKE padala_p_Page_32.tif
fb9528da5f49239146eca65535d4eec5
4f932da5b41cf877ef67a39d288630957fb20e8e
233767 F20110112_AAAIFG padala_p_Page_13.jpg
17f61f52acb5bca859e9192bf28bde91
9f9451b47ae42a6ceaccb679b05b0b3e6b99208b
2552 F20110112_AAAIPB padala_p_Page_51.txt
01b648ae0a7e7f36d7faf608bda386da
934d28bff3d59bf3cd9fe39b995fcfc7824d9b42
F20110112_AAAIKF padala_p_Page_33.tif
0c3f2ac034281b76de56dc9224df5a4d
918fef6e657299af8b16c00c727b1e4861269ec0
233461 F20110112_AAAIFH padala_p_Page_14.jpg
7fe04955573d307784729d51dd847a7f
31e97013d639f549f2fe41e8b8b52188a86c2674
1995 F20110112_AAAIPC padala_p_Page_52.txt
05002f4257104902e98d52ae0bd7417a
1fc483ebdcf4858274082b3ded9d6e9d251b6926
F20110112_AAAIKG padala_p_Page_34.tif
e4510b1e900ca62ebb6041b658adc0f4
20093c8005bd7655652ecc718ed0ffb8e422d122
193332 F20110112_AAAIFI padala_p_Page_15.jpg
a1fe49befcabca25b9935dfb4d235e8f
498c472c0240a8823fce1a17d2719a77cf428d88
1724 F20110112_AAAIPD padala_p_Page_53.txt
dc0c5442d33f44c1f210bb2dbcee4cb9
abf9430ebf4db1879559b3bb3465c2eec4bcd6e9
F20110112_AAAIKH padala_p_Page_37.tif
83a0d3d8f5a3606b602213a45b366376
fd556974765e10dd724c21741e1c555181039660
233558 F20110112_AAAIFJ padala_p_Page_16.jpg
03033e706cbe607b06f07a8e64f13bb0
96d1c9666b858611fe89194f0df3a3724ff875ff
1823 F20110112_AAAIPE padala_p_Page_54.txt
f7ec38e42166f2983161a9773c2b627f
2a74f6267ae706b591e014976f5fa887d6817890
F20110112_AAAIKI padala_p_Page_38.tif
c864eec9c3409b2cd8ffc536b0d995e4
3c0a0fce022dc8bd618ee4b7e0fea64521711381
239138 F20110112_AAAIFK padala_p_Page_17.jpg
8a11860db8951cf9091bf18ba187f211
cd67fd967d1fb912ab7a9e1f04ef9630128dfa6b
1453 F20110112_AAAIPF padala_p_Page_55.txt
2a94c4dd82e2f359a9aebe608fe53310
e0a2cad17ff0a2ceebfcc073e4b56568ebaa1e09
262857 F20110112_AAAIFL padala_p_Page_18.jpg
66b737646e249794937c2a68252e3a89
3fa072f36f65005b15fde7028028c4bbd260ebd3
1437 F20110112_AAAIPG padala_p_Page_56.txt
852089619c2685c7650543d6d1ade78d
1a7ac1111593974c11a49f5e9f054a06816d2d7f
F20110112_AAAIKJ padala_p_Page_39.tif
2600ae7cd8dfd18b331659f9d6a07c09
468abcb013207acc123205424823032a4e384f59
70965 F20110112_AAAIFM padala_p_Page_19.jpg
b369ea1787dd7da4af078d0009808ca8
2737daa331ebdcf6ca227162b39268a59213b5d2
876 F20110112_AAAIPH padala_p_Page_58.txt
c4feb6389c5c99b23c1bce8588ea2dac
035a7f2f29807caae88dec3ed9bfa948c78353bf
F20110112_AAAIKK padala_p_Page_40.tif
8a9ca9a937828a23af85fa254fc92d00
24da5183d0a7470d1c7400918dde67d6133dcceb
241551 F20110112_AAAIFN padala_p_Page_21.jpg
edb4e38a881c76df88068ce6c7d5071e
9068a1bf45f13d09d9daced5c6b93d4d120c2186
1321 F20110112_AAAIPI padala_p_Page_59.txt
7d5cc3dee07ed9353a5d65b324f3ed55
bc2f96f6a94d7f024c43c23a11e43bbeb7a9c06f
F20110112_AAAIKL padala_p_Page_41.tif
f17fae0b84ef7f72b9128f4d0765e591
e79cb5f7cb597510532633a6201c1cddae826f19
65217 F20110112_AAAIFO padala_p_Page_22.jpg
9f90f5a189aaff32a1d06011fca9d15f
87738c3ea9cdfb1737e729a2c4879372e2288033
1104 F20110112_AAAIPJ padala_p_Page_60.txt
36e88f62594f6df5e869d4ce6d63f95d
64e19d04575ac6b7e9fd74fcf194aa81091f7429
F20110112_AAAIKM padala_p_Page_43.tif
ec4075c26c812f02fc72b46b9cfdddf8
bceed9257f9af7b752d97c53838de0e4cfc4a11d
227595 F20110112_AAAIFP padala_p_Page_23.jpg
6682ab9a3cdbd775d4fbb1a44236ddf2
08945723adff5f49932e3b6d78c3cb0c2cab7bc0
1063 F20110112_AAAIPK padala_p_Page_61.txt
84dfff39b47ad49d759b237110249dfb
631969d80c8027ff67eb92bcc92d8d8d3f28c2c9
F20110112_AAAIKN padala_p_Page_44.tif
11d5c374a4b37bb332d942eed15c6356
a04efa77fa0cce51cab4be74dbe43024f1f23193
175625 F20110112_AAAIFQ padala_p_Page_24.jpg
8cbb16dc0ccd3fbfb6e0b5acf445ab48
50f5ae02e6c4385e88d59e675971bcf7f09f118f
1341 F20110112_AAAIPL padala_p_Page_63.txt
68cc0af9397ebadcd8b5e3faab203e14
5e435b00beca1eb66be83ad5fa37b87590e84c8b
F20110112_AAAIKO padala_p_Page_45.tif
85f37448ed11df193ec6d6966fc74b4d
f97799755e83b664898eea5c1e3f62e13c62f661
235739 F20110112_AAAIFR padala_p_Page_25.jpg
62005608214d2102bb57daa57d6ccee3
2b5976a04185aa643ad33e54f79ba9947ad30e8d
473 F20110112_AAAIPM padala_p_Page_64.txt
af55c9f6b7a1ec56e79bbdcea11167a3
f04ed1217e0aa86b26cfcb26f0480646f7d83172
F20110112_AAAIKP padala_p_Page_47.tif
4ce38594429af0ceb22fe99e26a0d32c
cf9a1387058bf4a6762a946705e9293513c489f2
232402 F20110112_AAAIFS padala_p_Page_26.jpg
8ebae02fb1c44ba3283f4f0f4e0a0129
6f055038faa7f1829ea4da34b8eecec7f95c753a
1993 F20110112_AAAIPN padala_p_Page_67.txt
eaadc44415eda242f7536efb35e48bd5
6e6f17fb710e39750a7cff798062de40ad8b7ac7
1053954 F20110112_AAAIKQ padala_p_Page_48.tif
c07fd52bb693e9532ff0a19f225fb9d5
ecbeda8e15a18fb313712d25021667d6b4224ec8
263994 F20110112_AAAIFT padala_p_Page_27.jpg
0928f9b8f8d261a621bbc6aa1f99ceb5
b64226be31c5887bec1403a5bd09f5d43b3b1235
F20110112_AAAIKR padala_p_Page_49.tif
6f2839f17c4b61c41a20bd3fd237b56d
344a0007c6943db81da357e48b2af7dea25fed56
230521 F20110112_AAAIFU padala_p_Page_28.jpg
dba52671e47d2c94f303077c166b9efe
d3db6bda2a629068f5592c3161fa57a94ed971a9
376749 F20110112_AAAIPO padala_p.pdf
918da96a82993ff80122a4c48b3d883e
e62f44479d420a24bb27d6147b124a48141098dd
F20110112_AAAIKS padala_p_Page_51.tif
f90bd99bdb1dcf43c57c94fdd47bebc9
968960833b3a0109373917c7e80752f7e73f2d9a
193670 F20110112_AAAIFV padala_p_Page_29.jpg
c38c0b86ee1e260b15db7ac614524809
f7913148ef9543e4e3126908df29c517d7062683
58395 F20110112_AAAIPP padala_p_Page_33.QC.jpg
e4f9612130d2c7fd2d2d74ca5905e85e
c96cd2bb67188406f5f31e4c44c93a726fcf6c07
F20110112_AAAIKT padala_p_Page_52.tif
5a58665c5f85a56812cb0a09ccc144b2
5f816c16666da5d44428fc96785795a0eea36195
195946 F20110112_AAAIFW padala_p_Page_30.jpg
941b61eca6d688dfc7ea3f6ff5d8b99a
037778010cb0213641fddae827ef64f445bba257
51127 F20110112_AAAIPQ padala_p_Page_48.QC.jpg
ee5a713782d90d4c3d3a7c39afafafdc
79b52e21a5855d227d61fe4ee95876c05d9cb9d4
F20110112_AAAIKU padala_p_Page_53.tif
deaecf05497b2d06b10f8520a80ba9b4
ab312eeca18954c86e31f53312699aa23d73c3c5
229372 F20110112_AAAIFX padala_p_Page_31.jpg
48890e7f35f12bfac250d2eb9726e0ad
f64ab40826d005bdd7acd20d8b124d241b2af534
30685 F20110112_AAAIPR padala_p_Page_02.QC.jpg
d579fe5a60a716e425b7d9636593d865
dee4d23d7f8b5e36d3bcabfcdd50ee0caec2647a
F20110112_AAAIKV padala_p_Page_54.tif
2993ea82f9e16ccc8de6cb13fa0f10d2
deee2a497c55aea89b837696bfe927fdc1e1ad2e
35764 F20110112_AAAIDA padala_p_Page_46.pro
c44142e9a5c8a7b5423d6d21d3bc8568
7862b64e9e14dcdb7dc720ee3ee4f40d6ff9b740
231041 F20110112_AAAIFY padala_p_Page_32.jpg
e46479970ddf780f6f26602286f7321f
779e7158ea61f51124f0f164ec3157c07f9ed5ec
43619 F20110112_AAAIPS padala_p_Page_64.QC.jpg
6de6cccb87a67a5883355a9fa76a7af4
586da663cb27b7e90588530ad24fc6ca9abee896
F20110112_AAAIKW padala_p_Page_55.tif
7666b554f4080343cdbff6339391c1bf
a95748e6e7a2c17efc384f44685bf06b60b3d08e
2095 F20110112_AAAIDB padala_p_Page_13.txt
0ed024c8ea5da1b59553460ac3d32386
6023912430935d79ea980e0b5374dc188ec9e11b
128614 F20110112_AAAIFZ padala_p_Page_33.jpg
8bf0319ea44ae1b964141980ad7712ec
facf2caee056fd6b10542ee5c30f47f1a3b6f16b
64037 F20110112_AAAIPT padala_p_Page_61.QC.jpg
6a2379dc07f2e129803e5afda4d60df2
2975b04cee0601505fc5891e336c4e8c04c16312
F20110112_AAAIKX padala_p_Page_57.tif
ec60f987801723a3b42cca80e7d8b9c8
81e92772c22b4a370fb159935ee5a15335188b6b
90086 F20110112_AAAIPU padala_p_Page_46.QC.jpg
6e0b091e0720391453b1b535b1a6aa62
135dd9c0588b9d66d6033547ff58282b6f3c05fc
F20110112_AAAIKY padala_p_Page_58.tif
daf1130db7636a799abde252b7c0caa0
c86fdb17da376ddf997b6fc6a1e16dd582a8229d
1742 F20110112_AAAIDC padala_p_Page_39.txt
f0b343f2cdd0091360a999511783d78b
dc5fc75788f1be4275e31e1a5052d58378743180
79130 F20110112_AAAIPV padala_p_Page_41.QC.jpg
b4baa17f02060e4187687a293091dc06
8fca6796408978d683d8f947bab5bb0cbcce8853
900794 F20110112_AAAIIA padala_p_Page_30.jp2
f151e45767c4d7b3961d0a3fe2109d6e
42f6446b1c01fbce9e4c08c886f898558387f1a1
43095 F20110112_AAAIDD padala_p_Page_04thm.jpg
3f4bc9b55af514cedd7675668def5d8c
13cc74b24e81aa097738e38dd40a1a46973e28b8
104050 F20110112_AAAIPW padala_p_Page_18.QC.jpg
9e68216870571820e81f87f903d559c0
627487af987584ca477530703e5c2633cb9a0232
1051984 F20110112_AAAIIB padala_p_Page_32.jp2
071878951aa44cee31beb40e89d65960
5a2ce22e59b00f3fec8169f35322f7dc58a13142
F20110112_AAAIKZ padala_p_Page_59.tif
390b4484b8fcb5caf821b6d71b64720c
8f45436e586910392085b54804873d1b15eeea20
F20110112_AAAIDE padala_p_Page_14.tif
e9a96c7fe6a70d70102d4df6444774af
3783672587befc9f9a69fcec064d8b606a6e4fd6
56921 F20110112_AAAIPX padala_p_Page_58.QC.jpg
78b3d02a8b76ab13af77ba470de6928b
b1072845f82fa9daaf75394af6de8e11ea4ae46e
442302 F20110112_AAAIIC padala_p_Page_33.jp2
0296eef91de3a0760e9a9214705d8ce5
731d3364ee0f2471db736ec7c12993db1505b40c
9097 F20110112_AAAIDF padala_p_Page_35.pro
bc2f4ce67d355f14afa63d94d4554565
0bbdd012c6c73432f8c20a51a58583fc54413efe
19743 F20110112_AAAINA padala_p_Page_58.pro
68fa88ce08a561b2c2e3f8cf0c751e66
a7025e7a7dabd494fb3b1692754f7a8bb61f0eb3
98094 F20110112_AAAIPY padala_p_Page_52.QC.jpg
d14abf977bd087f85fe844fcef81121b
c173460a55160f1914977fb7cd55772553d7ab8d
382858 F20110112_AAAIID padala_p_Page_34.jp2
1f631f19947096e3c1a429b0eb676098
158d44011ec7f1f06ff9e005929d19ac0b36519e
65356 F20110112_AAAIDG padala_p_Page_66.pro
7a4cf242dda4ba983de407b93eab6ad4
587e3ded398d9078b4ca49cb5e20dbf9ccf0aefb
19508 F20110112_AAAINB padala_p_Page_59.pro
71698ffbd4c2d4510b57afa4ff80746f
f576e9be2b2cecc85690c9f694fe5abbe930cf2f
48388 F20110112_AAAIPZ padala_p_Page_14thm.jpg
cdacd0fc82cbecdba2d835438e415fd1
a47e439fba99f76e857a673bc0e4d4a6d9a3a0ed
212838 F20110112_AAAIIE padala_p_Page_35.jp2
657d576a54811b9c93fe5b0fe4459550
49befd027833f468a3079a8271137720e7104683
534908 F20110112_AAAIDH padala_p_Page_62.jp2
09787c1c8f502ae34e15e003674d6f18
4e9706af5f748c1a682e461986760d5d409f1f40
19261 F20110112_AAAINC padala_p_Page_60.pro
807012e34c3ef8bc3023671170340fe0
84d445104bf3d922259106e9c5069af51111eef3
430087 F20110112_AAAIIF padala_p_Page_36.jp2
ec72abd2ece20d5affc0039d669882c3
9d53367f1c5d016de88b93480345e63f0660f81d
49345 F20110112_AAAISA padala_p_Page_20thm.jpg
13f814ebda9d2a41efbd2f6da4252d72
fe1b2c7aa997f45b0bfe79406fb14060b6961120
1051927 F20110112_AAAIDI padala_p_Page_21.jp2
1fa29ed5b98a15e82c8dd790fbcfa18a
1cf341ce0d4bc4d243554960355c3e274fdad2ae
21561 F20110112_AAAIND padala_p_Page_61.pro
e9d790c23855000095f10bd0ffc62fd8
89ec8e0b2c601cf27b3955855854a00f245f207c
1047138 F20110112_AAAIIG padala_p_Page_37.jp2
0d8a8d32a6e513dfa0b9a982f61bae20
bb0931aa245658f4c3db85c2bfe94a859a0b0c8e
103773 F20110112_AAAISB padala_p_Page_21.QC.jpg
942bf06ad46700ccc8162090590ed60a
5177a892881c8dafd727f0f0c09be4f6fa9902ad
266255 F20110112_AAAIDJ padala_p_Page_51.jpg
b0167e87c10c9ea7ab35cebb549e73f0
00312424f69a52d1aafe6928b5ec057da0939e4a
22752 F20110112_AAAINE padala_p_Page_62.pro
893ca0c91ac17324c84fbc22df887339
e3a515b21c0370fcbe2e580a641db05a211c321e
40941 F20110112_AAAISC padala_p_Page_22.QC.jpg
2da68e455b646097d7be45ac10bd5b01
257e36b64896143ed1c6a67f73403c4772a0a1ab
47027 F20110112_AAAIDK padala_p_Page_37thm.jpg
58076a148f2e99b68bad86c4492aad0d
304ca91803f4d22eeb05d27e982df75c9fbdce4a
26532 F20110112_AAAINF padala_p_Page_63.pro
cad0d95553d46c9ccbf01ef465ef7dcb
c04fe2c40ff7990de05f9b21c0ca27fd8ee9001d
938690 F20110112_AAAIIH padala_p_Page_39.jp2
540f34650cabf0f3fce5700a11e1d526
8488811d164f84d664d81730adb6d9e6c0103515
45453 F20110112_AAAISD padala_p_Page_23thm.jpg
b09b704a2c843de777ca2cb62e9f1869
a75e4b1a05fe3b103a093e90b153aeba178a132a
4861 F20110112_AAAIDL padala_p_Page_43.pro
5058d8f47411ffe91fe27e5b0a5f06dc
208a56a51a7df8120b704f231536bcc15813b11b
8850 F20110112_AAAING padala_p_Page_64.pro
141ea9fb5cd3d30db4d9ada89a4c5999
7b51dc62ffc985c672a91b776f2211bbc7199aaf
455302 F20110112_AAAIII padala_p_Page_40.jp2
f1baf22ea92cf9c6ea22443d454f180d
46bc7373bc2e532ff13d74487727e43e47c2287a
93959 F20110112_AAAISE padala_p_Page_23.QC.jpg
d50fbd71dc6baee5a0a6e4671d3bcfb0
3202d7cada7ea3be1b62944516b9aab26b06eda5
52152 F20110112_AAAINH padala_p_Page_65.pro
717d5e0a8bcf23042d1dc97d20c17a54
af7af98a9212b30569552dd956650208b9c0d1c5
752258 F20110112_AAAIIJ padala_p_Page_41.jp2
8bf6d2e8880ceb667d25e041fa7e68a1
488f6ffec130def4fd6ea47df3c33bb24c5bdb95
17575 F20110112_AAAIDM padala_p_Page_45.pro
117ba9bbec7563e1765e4281a5ee9911
c001cf33b13e43e582f6014550893bfc932a76e9
43597 F20110112_AAAISF padala_p_Page_24thm.jpg
f1d9cc3e68c4398a64aad2a6e6a33dac
f4b9a5094a42956ffaa4e46ce91990f29b268b8b
48866 F20110112_AAAINI padala_p_Page_67.pro
b312a01da7c68777bb1f6f1b77463806
5bbd81ed28020ff64225071f8f9685b20beef7d3
615156 F20110112_AAAIIK padala_p_Page_42.jp2
46bc7d562a128f2f0150c142874eed9e
b1d01fdb2d535da1048f078b641b43a069cac496
35621 F20110112_AAAIDN padala_p_Page_58thm.jpg
582c018936cfc51fb2fa4ed5e0079297
f90d8cae68e55b47b7feb32f7ab0dd3cc16469bf
48899 F20110112_AAAISG padala_p_Page_25thm.jpg
2cb44792eafe731da7886cec6212aecd
7a9925605127f940fe4b561af2fdf34c85f36062
16945 F20110112_AAAINJ padala_p_Page_68.pro
104ce2d74336c6db86636cfff7142441
e50579f6a14fb7368261676f182fa817d213faec
674046 F20110112_AAAIIL padala_p_Page_45.jp2
3e1302e484a68ded7b0b2adf6f93bcc5
ffc3b5bbc05615455100aa9ab6c2abafe8a9b524
88858 F20110112_AAAIDO padala_p_Page_44.QC.jpg
96692f7a4eba63c7118f81ff019fba46
56f50c37f251db309cdb09a59852f18ff73bac77
48800 F20110112_AAAISH padala_p_Page_28thm.jpg
ab48a2b810444f7f97452ca730021934
7537d6b919d1d2df552098a94a464b4f2143ed48
454 F20110112_AAAINK padala_p_Page_01.txt
2ba9218596cee0a77481c39bdcb5bc25
a5ed0f62f678ccdb87e87c6e9e769746199d7fd8
932577 F20110112_AAAIIM padala_p_Page_46.jp2
03d06c92ce7a83b36b4e09cff9e1381b
9e44adf0108752dd215542a856ec0fc67f34caec
F20110112_AAAIDP padala_p_Page_24.tif
6fb263d58a4425f5b187e7db1f51b178
f024b48b460412532339078ac792e34ce4366fdf
105275 F20110112_AAAISI padala_p_Page_28.QC.jpg
e70f77637cb5fe6edac0b2080cb1aef3
249f20536bfb5ccbd9326139d89183417d27a11c
111 F20110112_AAAINL padala_p_Page_02.txt
d0600c6bd25b2efdff731eb95818d6a3
3e5eb68bb28bfb5a26118a3d6453cb9b04628122
1036795 F20110112_AAAIIN padala_p_Page_47.jp2
b6d622943d79d3ab0e6f6974eed7863e
dc79a9781c2a4158b5d8c798d27445744a9fd2b6
268270 F20110112_AAAIDQ padala_p_Page_20.jpg
acae609651b7a5b97481eff8f41cc654
38f92c3bca092fc28bbdc29630053fd9cb2f3a67
45669 F20110112_AAAISJ padala_p_Page_29thm.jpg
3a0395023bf8a71be8c2f6db1358ada0
49f589883b1afe88bec1f536c878fc1457b157fd
73219 F20110112_AAAIIO padala_p_Page_48.jp2
4568a2d23c5dc3152db35624fbe6dbcf
c802d25670668c0e0d41fe3c54036341d3d021cc
42235 F20110112_AAAIDR padala_p_Page_19.QC.jpg
de99a78c119db900e68d977e029b67be
1f700ecf7b92d93ed1fb954c369ce53a39d35f7e
89554 F20110112_AAAISK padala_p_Page_29.QC.jpg
eaecb346f5f82d97882d2fa41c59aa06
25085465fc8dfa4696aea9b0731080dca7b5ad8c
2578 F20110112_AAAINM padala_p_Page_04.txt
68f95d273bb2a1df15290e8dc874b1ae
77dd72f881eec7140bf3561da71ce41cebb4151c
1051966 F20110112_AAAIIP padala_p_Page_49.jp2
c9f863f0fe8ede65cdd550e433782091
bb204c8591e186415fb9f2e359cb0c62895273dc
40965 F20110112_AAAIDS padala_p_Page_41thm.jpg
83732ff6e02e4b018387906f0390f759
b568b988efc81727885ee7a675c934eef0e90921
44701 F20110112_AAAISL padala_p_Page_30thm.jpg
7958e48ddb7042594a6f7926153fae08
686f66224a4811fcbecfb12be53db0191622912c
1700 F20110112_AAAINN padala_p_Page_06.txt
c0dc1737112eff7c6626417ce7a2713f
97108326f2858c752ad361d0fbe03f320b1d0e7d
870564 F20110112_AAAIIQ padala_p_Page_50.jp2
34a4bb5fdbf62752223c4c6eccac42ee
b2924780b41728ee5ff3aa33091aec270e46c796
28071 F20110112_AAAIDT padala_p_Page_55.pro
fdffc522abfe5aa3290a6c1b7e4b12c8
f79747885775246aeef1bc89830c419d8d0386af
46909 F20110112_AAAISM padala_p_Page_31thm.jpg
04fd003c841e7e31dbc6114266393d0d
34cedbf4b9eedba6c207106bec0444ef26b1d860
1846 F20110112_AAAINO padala_p_Page_07.txt
28640b46012a67a179af2d93ba7fd4ee
6bd9072b4fd1f9e1882c849a07ab1e0a0bcd8937
1051947 F20110112_AAAIIR padala_p_Page_52.jp2
c9b14d7728de7d66e4c5a76847f011ca
d7100f2bed18aea48e504ab093175fadf25cca9f
46418 F20110112_AAAIDU padala_p_Page_47.pro
5cdfeab85a8f59fdf12fa0d0d7ad24b0
463b0e92703145428deda1780af4613ceda6ea35
96192 F20110112_AAAISN padala_p_Page_31.QC.jpg
cc0bec4a1012a94f7317c30bbd1d558c
156d64352aa93ff6a396fe2c5fd3aca606be7f49
245 F20110112_AAAINP padala_p_Page_08.txt
6950fc16d0200d4fd517239e422ce60c
2f7f946f16b35d8de4ce5860bfa4c3a600e1e449
973253 F20110112_AAAIIS padala_p_Page_53.jp2
d2ea7d68170b9de690bacfc536cd1e5d
ea3f74c568bf04f54aa7ccc8290d6c10a6ea016d
F20110112_AAAIDV padala_p_Page_46.tif
6503cac1c66b3f226c081a27ff5336aa
138c84dadf76298c38178dd5ad6ae03e68e99c8e
47500 F20110112_AAAISO padala_p_Page_32thm.jpg
7908a464927cd4df9604a3d780513b89
79d4d2edc79c3932b1122d3a99fb8f8cfc32a480
1875 F20110112_AAAINQ padala_p_Page_09.txt
cc3b3fc445b4fe9d864f0f79d5c8ba59
82d9b0c3fab7be13f8ad6ba3d2b955123eabe379
989454 F20110112_AAAIIT padala_p_Page_54.jp2
9376c8703c37cd9b822a25113cd58f20
f63a8ce141f29fc5553a3cdf5d6ca7b8645b752c
1051981 F20110112_AAAIDW padala_p_Page_27.jp2
99e12412bd90f12a2fbd93c6e2f87b17
561c31e762537f8bd2c9a7057440d7f9da5d9ffa
37186 F20110112_AAAISP padala_p_Page_33thm.jpg
cb76ff6cec3958e29e1fd35d3e9652cd
e5193f7c6afd3f4c5e5cc78277e7566f2a278176
1623 F20110112_AAAINR padala_p_Page_10.txt
7383fe25df8c4f8dd415c04bbb31200b
d857e9856d5af8d3acaf0b784396d8c220c95b42
627622 F20110112_AAAIIU padala_p_Page_55.jp2
84696fad22ae91a496eb8a03aae96cd3
0e8c05a3f781e37cd61cd895d4434218a09e54a7
F20110112_AAAIDX padala_p_Page_36.tif
654a996ccffb4df161425030dcc1f058
0d49ef8cf1e3e91a5d534720e353078dfe610301
32626 F20110112_AAAISQ padala_p_Page_35thm.jpg
e48df4079cd96754f551506f45a5d57b
fad92fdf3ca5a7fa3ba879df3dded28d1ee8e007
1631 F20110112_AAAINS padala_p_Page_11.txt
7391d29864105037628afb0c2b4420fe
dfeba5a32e9329ccddde5bc8fdc26811f8b4bead
725113 F20110112_AAAIIV padala_p_Page_56.jp2
e238f70d7ef97891ce58a89b3a99db4b
fdf61c840294a70f4f9f20c61c9da9a3ecc88cab
2509 F20110112_AAAIDY padala_p_Page_12.txt
f9f4c8ed9c4e9218b66f3553e4de2d3b
b8d19843451b89ae598878242cd643d02b3f7fc7
2053 F20110112_AAAINT padala_p_Page_14.txt
79b235bc27cbc9b7d45817d17d217c67
b0676d4c0aca8be0e61fd91311a146cef7bda030
457078 F20110112_AAAIIW padala_p_Page_58.jp2
10f7fe32a2bb87c900439b80b8c8409f
8921152a1a79f133a321021ad7e50693d56704ca
45721 F20110112_AAAIDZ padala_p_Page_65thm.jpg
c40d55e8db33e076a7ae027c0f234b0b
fa51747ad3897e1ee5317e3853628258906247c7
42267 F20110112_AAAISR padala_p_Page_35.QC.jpg
aaa60f4fda183b03fb48130e11db2d58
132739ffcef41b6ce0baf5be2e0aea5f9c8be824
1783 F20110112_AAAINU padala_p_Page_15.txt
a7ca527f6fca740544638573565bf374
9b46f70cb1fcc6a8b08b5af57fb919fab67390c6
444389 F20110112_AAAIIX padala_p_Page_60.jp2
1124d44831586b8903f42fe4dba2c05b
8b556359408839f11e2f2f9dc00d4010e2f11caa
56089 F20110112_AAAISS padala_p_Page_36.QC.jpg
62115ad79375cac1f14c5e7d81995747
8368db151185ae0cc6aee41893d7fafe51750f2c
109785 F20110112_AAAIGA padala_p_Page_34.jpg
cc2c9f88e6b744a4bf889ccbd97da47a
996d344523766b82f63e067ce82b0dcf95eaf90a
488635 F20110112_AAAIIY padala_p_Page_61.jp2
34a8b19393140edbdfb519d6932ce5d8
c050c89b1c17a61d0a06b8d5b28bc75b6a38585e
2168 F20110112_AAAINV padala_p_Page_16.txt
646b8f1a51b777d33db6a1e16b0ba661
c8c0efb00af991ced47e6c8b78b26605a6785aeb
40555 F20110112_AAAIST padala_p_Page_38thm.jpg
fd33a085b75653c6c9187747f2070473
44be574c8a6550129396722062150e45dd84a9c8
72360 F20110112_AAAIGB padala_p_Page_35.jpg
fbc4b6514507b99a7c330a67c86f7e46
20788d2ae4e75dbfb9acc662fa552e596b3bc3a8
620527 F20110112_AAAIIZ padala_p_Page_63.jp2
09508ee54c84f253dda8b39b69576ae0
09f56eb0b4883df2958cc467d1a2caca5b884827
2350 F20110112_AAAINW padala_p_Page_18.txt
abb91ddc68c25e20c30441442786f90d
1ddb11ef5ca6b86aaaf9f7bca6e036d38b68b4da
71615 F20110112_AAAISU padala_p_Page_38.QC.jpg
6cc4b6f0d633e413f89a2cc7f657ad57
fb255a75fc5b5f2c97467545339bc7abb66ac0b8
122716 F20110112_AAAIGC padala_p_Page_36.jpg
1ff4840402425f12a28ba835bc8ada9f
532339d3f940cc93ed619605583b30f176cca2e6
507 F20110112_AAAINX padala_p_Page_19.txt
5f769e90c74f546d3974e5b10e9119c2
1758112426abf46694b98deea2ee215b71bbb302
46345 F20110112_AAAISV padala_p_Page_39thm.jpg
b24d12eb73599ac73a4a6c229b2299b1
7e0fd1204a5a51ced75e48e46f658ea800d38824
226999 F20110112_AAAIGD padala_p_Page_37.jpg
ff1436c12b299461f5da05ce5a7570f5
9df919b0eddf56f7a1d6021bb98d07273461fb0f
F20110112_AAAILA padala_p_Page_60.tif
d457a9229c4b9d2dadad32e7529a4f88
a0d7fa698070a3b6ef550f088e19aa4740191e9e
2527 F20110112_AAAINY padala_p_Page_20.txt
820ba988e52e35236a34564516ac8913
676f8311868628836d0292b931b0a11e3925453b
90511 F20110112_AAAISW padala_p_Page_39.QC.jpg
8b3f1bde89e7444af3154ad12be9ac23
5a72b237d8a31f478a1c3a98c9397a19d2955a04
162459 F20110112_AAAIGE padala_p_Page_38.jpg
6e192b229f833ac69b0783912d0f28fd
ed9d0ba716c96e41d9978b5487baaef78b1f2c5b
F20110112_AAAILB padala_p_Page_61.tif
ace486971526c3c707fe09ca828bf855
af6643b243f2a0fad1da8651c40bef25e07ea3ad
2056 F20110112_AAAINZ padala_p_Page_21.txt
0e94c5d7b196005ebf8f3c04e1eb2281
d488143f7b9977ec3aadf535a896db5c44cedd3e
36746 F20110112_AAAISX padala_p_Page_40thm.jpg
fda6dbbd408cedf3fc108f59b8eb2774
c3b2c76466322aa1e0c80d19c71954f69d66ba9e
F20110112_AAAILC padala_p_Page_62.tif
5c6164605915cb7f76ba29e98051280b
5905c9a90fbd29d18887bec5ca6ae6f11d719517
58342 F20110112_AAAISY padala_p_Page_40.QC.jpg
7fdfafd8a2eae5b283a426bb64690c47
e122258f12221aae0344b11450211daf88898677
207624 F20110112_AAAIGF padala_p_Page_39.jpg
fccb977af5e3ae2fbfc43b25805ec307
dd80a7f69b2fb72bea3680a744e91fe87e6ae93b
98061 F20110112_AAAIQA padala_p_Page_05.QC.jpg
c45f6af80b2572347f8b1e76b0e450d0
f28343de05fbaa9a87076561890f48eade2e684e
F20110112_AAAILD padala_p_Page_63.tif
0792ae592b72db7d0f66e37b26f16d39
b6babb734e51f5ec260a1d82da493e7bcb9f7d21
40033 F20110112_AAAISZ padala_p_Page_42thm.jpg
b563562b7c020b79f7584b27eac97789
d88427b1e6252ba4767d34c33c002fe3f495e604
115733 F20110112_AAAIGG padala_p_Page_40.jpg
c7971a2e6badebe8b95d5fdd81ec30bb
5b841ca50a28f40a1d4ad49baf118109547bcccf
88346 F20110112_AAAIQB padala_p_Page_15.QC.jpg
0922eb30452527f28800a179c1307b90
3613fdb7b2d3a05e12dd6b62658ce4ec67efbf6a
F20110112_AAAILE padala_p_Page_64.tif
5c7e8c01c3f2fa92d4b3c32fd256fe62
a5af79f6f5a9ae621ba16570077b4c67d867cd1d
165623 F20110112_AAAIGH padala_p_Page_41.jpg
ceeb2d1b3234d9d4f0cba865a8484480
2a47e46466a217582754b24bf1461800302da45d
31559 F20110112_AAAIQC padala_p_Page_22thm.jpg
a220bb9ef93e68194740bf7d3316f015
9bb77a82d08886bc6e3462283740091b174c0167
F20110112_AAAILF padala_p_Page_65.tif
610f354f827538b467acd8af79d95ad3
651200c2bc72e30af40684c01f41d698f809b437
92684 F20110112_AAAIQD padala_p_Page_67.QC.jpg
7755c11e2ebc2c8232e1db8bd7a60068
ede09d939df5db6aa25a9ed16e9e12cab23fc124
F20110112_AAAILG padala_p_Page_67.tif
0b779290c0232cb9bd1d802a2cf6bd6e
67308a2ad313391e309770ae52231219b4388407
133218 F20110112_AAAIGI padala_p_Page_42.jpg
d94457fbce00c6563ac37e0a58040dc5
8d118b1edddb189199a98422c90b789e6728355e
39306 F20110112_AAAIQE padala_p_Page_62thm.jpg
78a5e5b3ae18daa3298d80eed99e5194
b388a9bc85b8d590428bf6c8e350ce61dc4cf313
1051969 F20110112_AAAIBM padala_p_Page_13.jp2
e0cacde8f2a9f8edbe2ce0ae2dd8d531
129a234d3c5fa32ecd738f129e17a052a708deca
F20110112_AAAILH padala_p_Page_68.tif
bdd914942752a6bc734115b8c9a3096f
d3c0c93081370016abf92146539a8c49c9ec3501
70254 F20110112_AAAIGJ padala_p_Page_43.jpg
9297544c253d13928305b11ef4be42d2
c2450376166c5caeeb7c390e7e5a9e5994053d2e
104086 F20110112_AAAIQF padala_p_Page_13.QC.jpg
cc6f019ade64643f29cbe011d3f9bac6
240bd9ac7ceaf7ad990d88ed49fcba9f9ec9d795
F20110112_AAAIBN padala_p_Page_66.tif
67d0c4254388e04116e634127d2a7ab5
0e8f83d32cd2a2dd2106503db575318e498d77b6
8184 F20110112_AAAILI padala_p_Page_01.pro
2ec47f1982ccd1a90bac0c5088146a55
b81619ba069779f5732cc539da9652378ae7f0ec
193594 F20110112_AAAIGK padala_p_Page_44.jpg
0d1ced948832d7e03d42162524e19345
c5607514c822584e09f9a86a917df59b743277b4
48191 F20110112_AAAIQG padala_p_Page_21thm.jpg
34fe1179b01243a2b534d2591ba58a26
5f8749966d326faa38bb2a11211f5dc44d3ac157
F20110112_AAAIBO padala_p_Page_50.tif
5e655c87e43e5ae97a5bba147ce78a61
6eb0063e22769e67be561acdbdec4aa39400ef17
1147 F20110112_AAAILJ padala_p_Page_02.pro
37fd8fabb23be89e49642ba6d558ba25
169f83b1f85da7c2812845280b2fcaedd69c0f90
198247 F20110112_AAAIGL padala_p_Page_46.jpg
967473c0d99b46ec2e6ca79819bff34f
3e7b2eff78b0c142524609ba8f609362e47a5260
88335 F20110112_AAAIQH padala_p_Page_50.QC.jpg
bae5d7bcd4a2b3cff109f859ca7d3f64
a3e95b49c820f79e51eb2a6da7bbbfb015137455
1051972 F20110112_AAAIBP padala_p_Page_31.jp2
9213ca469a35c355d990b091e56281db
227d1f15782250acf999311ab6116405e8eabe97
140038 F20110112_AAAIGM padala_p_Page_48.jpg
b5a9b823d89233317d45ef929517b2e7
85bf6cff7140c7ade313c84a92f675dc877f19d4
35396 F20110112_AAAIQI padala_p_Page_68thm.jpg
a9b528c1e2ad16f685242685f73a0ca3
e4995f49bd3fc155ec2465c2336f313a439df7ef
8777 F20110112_AAAIBQ padala_p_Page_22.pro
0bc370f3dc3af393013df8f3f6d4fa45
4579df8ce78cee0bb2cddb31f38318b571a1d487
14176 F20110112_AAAILK padala_p_Page_03.pro
6a60a8ee9f79611b8b41fc7e7e7c83ff
e95b592f85714f4d0351ec66d8b3aade21dd20f1
183138 F20110112_AAAIGN padala_p_Page_50.jpg
c17857adb9b5c09b229c16403a1790f4
b52672882c45c0811a9439386a9b0b07b3cfed95
87614 F20110112_AAAIQJ padala_p_Page_30.QC.jpg
16579cf42434e42376c84f27ab32bfa7
ae24adeab013cc76e432f70502c7764c2917df41
F20110112_AAAIBR padala_p_Page_19.tif
d0d737ed488d4258fb3b2a33097bf982
0d3a9947be15689ace40ce12ed718706fd7b8162
56728 F20110112_AAAILL padala_p_Page_04.pro
f38d21d181aa142e06408651a9452e60
6815d78169ea62ea1927ffb800b4d69e82b49624
230017 F20110112_AAAIGO padala_p_Page_52.jpg
0cee2d3a3b3fa4d84e7776b82317cf29
11f5ff1876e7d11212bc998fd096e11330867410
35746 F20110112_AAAIQK padala_p_Page_34thm.jpg
e912f688ce0cd3af50af11ffebf480b2
1029e92f8dd1bca5aa35ecb4a6eed56b2cbb1bd7
2112 F20110112_AAAIBS padala_p_Page_65.txt
fdfcf8f22fdccded09a0895ec8f6a4db
fa23333a5769a4dfd95d5a44f3cd01c384543ee8
46701 F20110112_AAAILM padala_p_Page_05.pro
ccc3140f91d5b867764f8ab4a4bb5d1e
f88823ce8c07ad04a4a663948d468b6437339383
205591 F20110112_AAAIGP padala_p_Page_53.jpg
69aff3f62620a05494d239189a859b61
72418caacdbe9ddcad697ac7ccbe6df8c6acdfc2
47793 F20110112_AAAIQL padala_p_Page_13thm.jpg
ec1a7b0b32bc5a083ed55155e4728f5b
f6536a1f3dd7ae1b60f3d70cdb314fb9a0ab1311
177979 F20110112_AAAIBT padala_p_Page_11.jpg
7526117d31999d24b0c5abfb6d759ecc
9c36f297e715573274ee7348c5a4ea76c462caf4
42574 F20110112_AAAILN padala_p_Page_07.pro
ced07f5aafd5749a8e13c85c7ccc27e6
cd554e48985f1b405a4f0de0a5acd3a5543180e8
215160 F20110112_AAAIGQ padala_p_Page_54.jpg
9f18c476c69c95111f6ad1e3d07bc8af
5b34184690e7c5ca351d392705876e4317af1033
41117 F20110112_AAAIQM padala_p_Page_06thm.jpg
3a7c12a9641e3d009404a8a7ea262f43
7150e0926519fec9e4d648322aadf6bb4f2616f3
461979 F20110112_AAAIBU padala_p_Page_59.jp2
abdc4fae0329775edc53e2dfc458ece9
d0ee73caf742bea93afc0363d1ab5d36a68abe01
6035 F20110112_AAAILO padala_p_Page_08.pro
1fdf4e52caa20296c94affeddf25edae
1d8500c22cfb4fcdf94ab5c51da5ebc6e8b76e99
149794 F20110112_AAAIGR padala_p_Page_55.jpg
002298cbad8b4223711273cdb8edeb47
c1303ee442988fcca05df3028603f4733cad142e
40813 F20110112_AAAIQN padala_p_Page_63thm.jpg
9f707fb1138ac42b9bbc8ddc54bc8379
77ba9f4adff1c1e3c8748f8a0c01722bc41e1663
232098 F20110112_AAAIBV padala_p_Page_67.jpg
501e60d49d57934c9751f19cb0d72fd1
8e0a9c6a59f177a906b4d65f547d29b65291a6b3
40013 F20110112_AAAILP padala_p_Page_10.pro
9581edba0aadb0555c26600d78b6b2ff
dc531e3ae034017cad3f9e5594dda452ac978227
165278 F20110112_AAAIGS padala_p_Page_56.jpg
66645f061c54bec3cf73e3527edc7602
38df7a60a819d9f678712d1a69e35dcd316d3ee3
56754 F20110112_AAAIQO padala_p_Page_68.QC.jpg
031f30ee38bf8694056b456f3429c28e
c6e69ff95eb9ba7886acdf96e46e92b1b1b3732f
38515 F20110112_AAAIBW padala_p_Page_06.pro
069ba2e129994a5eda3f06424d0a5b8c
36f47edaeba530f34ee9e1a57ce90e3786a3f32c
37822 F20110112_AAAILQ padala_p_Page_11.pro
0da5ba483c2b4108838c0fdd0eacc3f4
8b6643fd0c1bae701430aa2a81803ee32df94ebd
144935 F20110112_AAAIGT padala_p_Page_57.jpg
b75e24d3a8751883a883a165ab159998
e961dffe205758892c29b015214a0f4021a69a3d
171703 F20110112_AAAIBX padala_p_Page_06.jpg
0fe6f3c88f30d709f43a89a06a19dd37
0db855df7647d29aa827a426af4d19ae37b5797b
60992 F20110112_AAAILR padala_p_Page_12.pro
aa5a6830a65218500872c8e48b387917
c8fdc0bde862e34674ea807b38f2bbc6ac1f55a0
119433 F20110112_AAAIGU padala_p_Page_59.jpg
8faa34dde4558109b829394b846fdb66
4a9566ed3f776a9c1866ebe7ba2cbdba262fbae2
43238 F20110112_AAAIQP padala_p_Page_11thm.jpg
4e0935c9a5282adaa8deec8b9a2e0f30
24b912aa4b0e083ce3a79ba2ea1ba7321902099d
F20110112_AAAIBY padala_p_Page_16.tif
47ec751310358f81428e972033684a75
4d34e3856e049e8bca29fde80b8d55010ceb9a53
51031 F20110112_AAAILS padala_p_Page_14.pro
ac2aa110e7edfb343cdeae0ba56d589c
a2c08c4db78dcbc3dc9827ac4b64508e7e5214e0
116168 F20110112_AAAIGV padala_p_Page_60.jpg
0512146e898a98196237e30b2932aea4
7b3dd6f3ba358100e58b95de28475867126df209
47835 F20110112_AAAIQQ padala_p_Page_05thm.jpg
a95c7f1ea83ca7a61b65d59190730d96
3fd83c98fc52d570def9c8f341d53440113d7bd0
231985 F20110112_AAAIBZ padala_p_Page_49.jpg
e23bc8b43d4b362fa3e69facfa6d4ac3
475e2c3b845fe376240eb44bd4bfbc98481e45c2
40656 F20110112_AAAILT padala_p_Page_15.pro
e72fda304978017e39078d0b25c2f622
8c5c5b4314ff5d396444a8f713c64cd4edf60cbf
126782 F20110112_AAAIGW padala_p_Page_61.jpg
4a0a1106bfacaf420ef07bad6850c5f8
7891d72b9060e96d770a25db1c9de143cbf9a99f
53304 F20110112_AAAILU padala_p_Page_16.pro
2921d49a2e92eca84e2e014ff9b8f200
6fa25cf02eb88a804e26c44bb7b15160123ce648
127370 F20110112_AAAIGX padala_p_Page_62.jpg
bc905dad599373a71c399000ceb2f453
ed3a18b0c1cdf6750c02771ed9bd777924435c13
97255 F20110112_AAAIQR padala_p_Page_32.QC.jpg
9e09313c618ae7e39593ea8074fef8c7
e504f73677146ec2e5f13a633552b183b6bf3451
50667 F20110112_AAAILV padala_p_Page_17.pro
cd4a6893ba662c379961151a1b96ff8e
19c2f81f56688873337fb3212bd2a0d25f8ef193
56584 F20110112_AAAIEA padala_p_Page_08.jpg
706ca5c2b1978f89e4af082a6cef68ed
78153d981e6dc9477f80d83a4eb4af4b4546d7f1
71698 F20110112_AAAIGY padala_p_Page_64.jpg
318db2663100564e8478570ae0117ac3
d890bd9961cedcaab218d5fbc2bc6240d482961d
96420 F20110112_AAAIQS padala_p_Page_37.QC.jpg
b49c01f1d7110cdeb8c180e855371fc1
33eb07755d28036ea38fc97f178d3a1aaa135c45
9176 F20110112_AAAILW padala_p_Page_19.pro
100929b56c3a7b7aff28a37458d37724
fd9514c7a9e723f418d1b34016b2c41c6e33b656
67149 F20110112_AAAIEB padala_p_Page_57.QC.jpg
743a558e80e5fbf61d7e17bd2a5a55d3
3f5308ea42e2ffb57573fa2c9213c7898314a701
241908 F20110112_AAAIGZ padala_p_Page_65.jpg
cbc5445240e17133b4de6d62cb8d1048
a2b6c8bc243ee08cfb6816b816122b85838cad77
45096 F20110112_AAAIQT padala_p_Page_10thm.jpg
61e2a51b999617971adb02846d035c02
54206ea661db17547a392020859b3866dbd4b619
60507 F20110112_AAAILX padala_p_Page_20.pro
5324799a0ae49f2c2eb444a148bfc216
28f1f72940301502bd27574d28911ef779602a14
F20110112_AAAIEC padala_p_Page_42.tif
ce0bbf647056e84e51662a9369f89b02
67cb21553b230936e3a170db9e6cfd8df6cc8251
113628 F20110112_AAAIQU padala_p_Page_66.QC.jpg
b4e81eb9eaadf47005b1905170526b82
b95bb09cf24d65b924dfc09985175791cffa9e7e
208218 F20110112_AAAIJA padala_p_Page_64.jp2
10a4dfae5ebed1e15a1349e2d714fdbe
54a2ebc2507bb14976f1dbec0fedc77898a0c5d5
50977 F20110112_AAAILY padala_p_Page_23.pro
1e9be92f8c7b3d71a5d405d9586f0baf
7b2fbed68890c39d4fb00a571078308edb5dd48e
77875 F20110112_AAAIQV padala_p_Page_24.QC.jpg
2735877a18eaf4dc3d470917aa868e1b
5b7b15b98ed744045253a9dc2edd905fea2753ac
1051968 F20110112_AAAIJB padala_p_Page_65.jp2
81345c512190bc583b75854a6cf05045
38a162cdf21cc2837a25d30924f7b9a4f47e41e6
19885 F20110112_AAAILZ padala_p_Page_24.pro
f7206cb938854ddbc6b38f0f403af218
00b312ca06924d2a9dff65182126831411425b45
F20110112_AAAIED padala_p_Page_25.tif
8d19420e807d19f8bce37a8fbe43f51c
f64fb5f5be75b099e7083e7b0e7bb2815ef4f07e
102313 F20110112_AAAIQW padala_p_Page_25.QC.jpg
d8bc88d1a07e71f99cb65e4a1666d05c
acfc5013f8082a33a28249b94be5345ee543344e
1051888 F20110112_AAAIJC padala_p_Page_66.jp2
47cd2f9aacf45497ae616a6bbf180b35
888ab2231f4bf5bc57b621f0f50841b5b9f31465
101385 F20110112_AAAIEE padala_p_Page_26.QC.jpg
3c502bbe6a7aa8971f11c4853b5cab26
0457537c02d212d6342317b68b155850937a40f6
48983 F20110112_AAAIQX padala_p_Page_26thm.jpg
25c7afe8238f5c9089b571d522a36e6b
a00bc527572e01fe3bca22addbf1a604e07cc1e1
47342 F20110112_AAAIQY padala_p_Page_18thm.jpg
ec0934e8fed8af5b753cc3fae3124dcb
1d68cb1ef2b744caf3826ba28d85679d3142bf84
F20110112_AAAIJD padala_p_Page_67.jp2
483950bf863325d816a014965fc8ecf5
ee15d27fe959949ce30f52335d79932048937ac6
163542 F20110112_AAAIEF padala_p_Page_45.jpg
b503d81eea715cf523a00b5a9f33aff1
ae4b9618126d8ecc6a177509da72755e62f97fe6
432 F20110112_AAAIOA padala_p_Page_22.txt
bedc9587a2ef9b8a9d96767584fb0700
249c41216556036bfcca45df9e1eef9b1e94bcda
16103 F20110112_AAAIQZ padala_p_Page_48thm.jpg
ad17e8552a4043b84226a603200094d1
1462fb63a035aeb26c5900ae5c643691c314e23d
434358 F20110112_AAAIJE padala_p_Page_68.jp2
cfde4266353474613951bffe6802415f
56a451386d6354b2c418e1d584298b56d9ee3747
2628 F20110112_AAAIEG padala_p_Page_66.txt
421d09f458eca0f0fcdde2c24437c9be
cb4f20e8245f725e46f879a9b1c1b900ebf7163b
2176 F20110112_AAAIOB padala_p_Page_23.txt
68c0cc816116479c7df04ae83d25406e
ba6c1b038dcd2c2c05372acb08d7c90224a665df
50171 F20110112_AAAIEH padala_p_Page_13.pro
2e487340da0f3949a6dc3ca983f32ada
ab5bf4ac18e426a333f9c1a83b74be9d3819ca35
869 F20110112_AAAIOC padala_p_Page_24.txt
fe5dd16bcfe095a5ca923d7c924fa66c
c2c697bfbbcc4727676ff0fe1059b4b5a026efbc
F20110112_AAAIJF padala_p_Page_01.tif
881a3d199f5358e49214b4f8471cdc1d
bbae0ba64d15fd67ba46edfd3953c6bf5f98d884
64949 F20110112_AAAITA padala_p_Page_42.QC.jpg
838cdf151899620531024af5c8d443b8
090f7b0d0c4a36a09851a038fbd44fadf87df03b
F20110112_AAAIEI padala_p_Page_28.tif
aada17a65b3d60faa3ad8b657dfb8c61
688353f03040c749f325b927bb0412d1fa8dfb2b
1973 F20110112_AAAIOD padala_p_Page_25.txt
c7261f87aeb01593e753d878b51e5608
de6987f9b3022b4ca848bca7a8b31700d0a5f959
F20110112_AAAIJG padala_p_Page_02.tif
2deb1082154a1ba02561c2301c9c11dc
157ff7da2d0605c0ffcf5998d7dcfefc286ef762
32130 F20110112_AAAITB padala_p_Page_43thm.jpg
1f22ceb5b1195f950e0aa0dff479e1e8
ad81a70524cbb6ee0e32015a4d2f07fa82205db9
103507 F20110112_AAAIEJ padala_p_Page_20.QC.jpg
949be273002609f3a1e3a7369f0ca68a
bd60b6b461b24b7a2c5fc91cce74cb7412390a31
1978 F20110112_AAAIOE padala_p_Page_26.txt
6693f41dce5dfa9f279527e98e37484a
babafaad9ed0a46dd8e7776f0bb930709caeec66
F20110112_AAAIJH padala_p_Page_03.tif
ad37531d0a69085d9f95cdc903dbe6a6
e54e3ba291fd6183b579b5ef0abe9974fb9fe04e
44895 F20110112_AAAITC padala_p_Page_44thm.jpg
16096c6a0c5b02900c70a73936533d2c
746a0351d28aa047ddc72ceb84b429fd7f3d41d2
725 F20110112_AAAIEK padala_p_Page_68.txt
6f96aee242f58f51080594f86eabbc72
c3ae5513a19018adb9b42dab438be363a0510b9a
2349 F20110112_AAAIOF padala_p_Page_27.txt
2c918ed1e0c5d7c2dcf0e6295e240f32
f5f9daeac6de5ad450e7e2f37c4973d11ad3f283
42143 F20110112_AAAITD padala_p_Page_45thm.jpg
9515e9ab0ac4e0eaf41890f0a314340e
710df66254dd0679adda276117d6603b9ef41fe1
71826 F20110112_AAAIEL padala_p_Page_56.QC.jpg
ac23802758f1cd437fbd350fb7835417
4112e6212d615a7f987cdbb2707658dbbf2c123b
F20110112_AAAIOG padala_p_Page_28.txt
a9b471e406e88680381210996b24fbf4
60b1be67c7b2a3bf3bbbb43ad7e03f1081e48705
F20110112_AAAIJI padala_p_Page_04.tif
c28a1bf9e2e2cdfe5be90af92f34cb8f
61fc0f43ca857996fb3a005b01556ca1cb13f697
73322 F20110112_AAAITE padala_p_Page_45.QC.jpg
3ed8b9b5ff51be1b2f68793bbb3516bf
e698b13c4fddf7ccd876eda726285862942cae0a
34348 F20110112_AAAIEM padala_p_Page_03thm.jpg
546b8755a1db8bdc558e2e6e71d72500
47eb1fb23fff0f89e64178f379e76e8df983ba7e
1762 F20110112_AAAIOH padala_p_Page_30.txt
9573ab5e8ec0a35c245f2828b91ba3f5
daa1382ff73b124fde3290565ee6aa66e88350cd
F20110112_AAAIJJ padala_p_Page_05.tif
12a1eba3be16d4a168714c4e91054895
f1f3efd276e590dd61046223dbfa570485f73ce9
45861 F20110112_AAAITF padala_p_Page_46thm.jpg
04afbfd698e19608f41f61eb39670d2e
69a96f391955e97366951735cd836d2f3123baa5
2082 F20110112_AAAIEN padala_p_Page_17.txt
0667ade1fc3430ad01abcc5b810c1cf4
c9dd1d0f933075a3562340d55dcf6cfc940b954d
2002 F20110112_AAAIOI padala_p_Page_31.txt
827f4e180a8920c22394c86972621afd
17d77c87489d9093c2932a93dc6c65c471ce4f22
F20110112_AAAIJK padala_p_Page_06.tif
91a5bafff2f636c949d809ce3b41f46f
63f66e6da45a9331e98643d1b432f0c4b5abf314
46758 F20110112_AAAITG padala_p_Page_47thm.jpg
84fb3b66ac614c8854161424a0005706
73f761a867c26a3e615fd21a02b7fa06abb417b1
54814 F20110112_AAAIEO padala_p_Page_34.QC.jpg
cf2f2a6234134097ed9389199182f3da
fad9981860a679df57f50145f22296a8f3725c8e
2114 F20110112_AAAIOJ padala_p_Page_32.txt
520d156e19f4960a2f2f3f669ed114cb
cc6bdf641836d1292b6e387c0ecdda17d149a784
F20110112_AAAIJL padala_p_Page_07.tif
12450191da8c88d065399a4810da4e01
d7be649ba30497a4212c619c25ae80a547261ab5
94720 F20110112_AAAITH padala_p_Page_47.QC.jpg
da79d10484221bdd79975ac4353a8533
44d68fbe26999306035f78bcc3fb8e4ccf17c2bd
1039 F20110112_AAAIEP padala_p_Page_62.txt
c54b84dc0bf7943e9c086d12bf841362
d8bc126123b597255bae19af66a02ee6c3bf72c6
1062 F20110112_AAAIOK padala_p_Page_33.txt
cd29cff701e357c09b6784a57d4a8cf0
e0d98c72456b87998a6a73ebf6e9e1672b8e4151
F20110112_AAAIJM padala_p_Page_08.tif
0af840c112ad643dc266c766dbe5b417
be1a2bc6cf358153d8133a972ca84ceb2014e0c0
47314 F20110112_AAAITI padala_p_Page_49thm.jpg
b69e10f0a3535fcadd88a14203aac6f5
0980726dd72d9f186374e0276c65c2183b88fa3c
1664 F20110112_AAAIEQ padala_p_Page_29.txt
0675646e509fdf5b5fb53e79f76e8399
7f82e30047827d74d32415b505881d878c503063
851 F20110112_AAAIOL padala_p_Page_34.txt
2cbc82af0bae9faf3e3007996b39224b
435902a8bb3de09d39396fd58abaec8700c23c11
F20110112_AAAIJN padala_p_Page_09.tif
3c37d5df42ce57ea185bd7d30c1c0675
44bd741e127bb4f43c43b6adaecbea161c6b056a
100448 F20110112_AAAITJ padala_p_Page_49.QC.jpg
d8e1f5770180c815564637cd1eb3dc30
7a480f8ad37aebdfa4de336db85cfcc23575fbcb
201293 F20110112_AAAIER padala_p_Page_19.jp2
605dc9a848313046694763fb6d7cd518
4da0fa6e12e074587e3fb95761b508c9fefaefcc
523 F20110112_AAAIOM padala_p_Page_35.txt
069ac8307acd88d749f3bf1b6c0cdc51
0f2120f52c62a8c3fd5e381cd793d1e3b6ae6898
F20110112_AAAIJO padala_p_Page_10.tif
47c0fdb1d715ef918dc6c6473289c0a9
bc131654e13e55d26eb60aa2998ce2c3a1643ae4
44016 F20110112_AAAITK padala_p_Page_50thm.jpg
ddf875022403d1c79a87f5738872261b
6eb3f14a3cd043090d761e5102953ece1c457acf
620429 F20110112_AAAIES padala_p_Page_57.jp2
f704e53cd1128fde4d5ddc2a6a4d61fc
40c1c581f146fc55bf22243ff694cd80be674488
F20110112_AAAIJP padala_p_Page_11.tif
7fe9f4e37b66daecfb012299e9a7614f
99e59669bc28e9e01ece448770a4ed23e664572a
104703 F20110112_AAAITL padala_p_Page_51.QC.jpg
77f5b0a1aedd040ee7868816cf6f906b
eda6a46df28fe94c4526f3cf8cf2e82b270ca51e
32527 F20110112_AAAIET padala_p_Page_64thm.jpg
2366f37269b06ccfaa79627f8d1c28e7
9c7bfe938f2932fdafe5452288078a9eafee12b9
934 F20110112_AAAION padala_p_Page_36.txt
10221e7e125179eb6aa06c3cb7c4a967
c60c4c58a464418d28567807a31b7a1388fa791a
F20110112_AAAIJQ padala_p_Page_12.tif
65f0069c97f8e13ca5d95b751be5c93d
383607f2bf96c2b3089bc9918589203e6899452d
44104 F20110112_AAAITM padala_p_Page_53thm.jpg
ee1ecbf93a04616be275cae799b42033
151a9203a2c9af101c3c6575d0f82d85060080c2
1164 F20110112_AAAIEU padala_p_Page_57.txt
7a0cfe8d162cee4d95f5da3c3cbadd2b
a80bb78b3729878cf203954e775bb6b4bca3a12b
1949 F20110112_AAAIOO padala_p_Page_37.txt
34a66da9e0ffaf0477444a1cc32619af
e2bdc1b373fe83e22b1cde3a28e0da375d49687c
F20110112_AAAIJR padala_p_Page_13.tif
cfdc46e5527de6e536bbb2c19dcd9508
510571713be317a1a63c2503ba67727b96a7d326
84904 F20110112_AAAITN padala_p_Page_53.QC.jpg
c6fa0dd282a41ba4ade3e189294a0d53
645ced9a1ff56bd1c5d4c9bc6345ca04d0075f7d
49472 F20110112_AAAIEV padala_p_Page_25.pro
ed2468cf940841183539eee53c1331a6
c781f066c8497e98caf2dde4b6a9a6ab578e4980
1347 F20110112_AAAIOP padala_p_Page_38.txt
7f6c6798dfc4e599650ce886b8d3cd90
352616a8b07a8f2cfd2591fa88162a2634cc1a94
F20110112_AAAIJS padala_p_Page_15.tif
641213a6c71a0f094e48684d8eaa3734
92bcf9490bfa41cbcc172bbaf2007d1d5a8b97dd
45805 F20110112_AAAITO padala_p_Page_54thm.jpg
b0f1389fd0493159bc3c0b76c239feab
ba9b8922d5bce8179ed7ed00ab44d696206dfbdb
80421 F20110112_AAAIEW UFE0002826_00001.mets FULL
95ddd7253d81203ad6f808c7a1096f38
d325bcd79f2189d169799590b6fdde2174588aa0
857 F20110112_AAAIOQ padala_p_Page_40.txt
60507b830462338b8742098ad73174f5
1083fc7c64858fa4443da91256b1d21cc80055b6
F20110112_AAAIJT padala_p_Page_17.tif
5459b44ce54db9e949840bf76b3b828d
a46d741dca35994f0e90967f127e6658b22d9bd7
90355 F20110112_AAAITP padala_p_Page_54.QC.jpg
5aab8a33dd05815a6a50baf41ab9fc4b
f34fefc9b4c0d0919e81a7702adf33716f4fade1
1459 F20110112_AAAIOR padala_p_Page_41.txt
16e6904abf45049d8e32ac7b31f46c90
bb5ef1b3b26bb9de8f7c19ffe65f7d23ffe8c237
F20110112_AAAIJU padala_p_Page_18.tif
067689f3ca0af23d9873c84cb029117d
ef525c35c72b1ce47b675580bb2d7fb09940dd16
40255 F20110112_AAAITQ padala_p_Page_55thm.jpg
570c2fff62d1ac5ff4db5e28a62f1623
a706e7b3596389109d3d91195eece2a8dc22229c
716 F20110112_AAAIOS padala_p_Page_42.txt
5c1999b2dcf61055dc2393023fcfd06d
ce5b38738de6270b486b8bce3fcc91ad2fdd2653
F20110112_AAAIJV padala_p_Page_20.tif
4beedbd49224f9d08b63866d6db73e28
6c9ab962ffdf71a8c52ff639b5cf949aee054e25
1051946 F20110112_AAAICA padala_p_Page_51.jp2
666c359da9b6853c40708eeff3d130c4
b243425b73e7f5f0f244bd279bd29433c1002ac4
38469 F20110112_AAAITR padala_p_Page_57thm.jpg
971fdbe211216968fbba78f9e6032f35
c0fcea15e35c62b4a8cbcfcb5eed512ad0e74dc9
83304 F20110112_AAAIEZ padala_p_Page_01.jpg
283a93c73870a4c0e221302ae8554e60
d205fbd4440a278fa222398848a558d12fc70eab
243 F20110112_AAAIOT padala_p_Page_43.txt
bc220071163f8a4602f68f59ce4333b4
c578b33dafb6f5dce10bccc1a01c320afb9185fa
F20110112_AAAIJW padala_p_Page_21.tif
cc6611aa06c8f2daced3ab9c44c89f3b
47667cdcc10c5335899f21ccebd2b32d80034a70
1797 F20110112_AAAIOU padala_p_Page_44.txt
1477bd012436f96a1d16595f9e023cbc
f5cd70bbbeb57827b5e11c02ded3f8b84763337c
F20110112_AAAIJX padala_p_Page_22.tif
bf8cfa3112cd6cf1c73eac0024d8198b
834ce87a73aff2cddc39f402d2e4a06bb96fe2e1
40197 F20110112_AAAICB padala_p_Page_56thm.jpg
f3475406cd88c9da7b5f2d4969ee4d03
b9820ae90d6d4e516787a7bfa926650a5fa6741a
37452 F20110112_AAAITS padala_p_Page_59thm.jpg
ea0b13fbd2d3f6b9fd005a9889dde5a5
87070fb0898415d8cc5fb64093a3e31bc63353fa
1068 F20110112_AAAIOV padala_p_Page_45.txt
a6fdc1c0a59b0905cd2a2c578bb0a3c6
6e58377795b94ff2742046a23e462634af97df05
299042 F20110112_AAAIHA padala_p_Page_66.jpg
b6a33923104058caddf1ea2544b1cd63
114d3ff4c5737f7201eabc3a68dc4a4741dc7669
F20110112_AAAIJY padala_p_Page_23.tif
5c8fb76b5bd0024e19ab9f2f55860384
274d67a46e45bac7df1131a70518a97bc4a93828
70638 F20110112_AAAICC padala_p_Page_55.QC.jpg
452c6d5267e438037293f538a79c54ec
e649a09ff1e3bbcc8a451f8994eb885c7b4f756d
59191 F20110112_AAAITT padala_p_Page_59.QC.jpg
17431f3374d155771361e80583e30ace
685e704f08a1ce79ddfb9f69d400e348e0943196
1602 F20110112_AAAIOW padala_p_Page_46.txt
c8b1bf1e2c589bb5da7c50f411bf89d4
a3974ea4189922df4f589afdb32ed9d80aef904a
107254 F20110112_AAAIHB padala_p_Page_68.jpg
f9060af5c52f73926d92e757f7c42418
83b5223a62b42ad5ff72039d3f2838ed5f16556a
F20110112_AAAIJZ padala_p_Page_26.tif
fd68005c51b2034ea2958d6a269cf4ea
62f521e590c34ed6255d81ee70faf752e5484502
89336 F20110112_AAAICD padala_p_Page_03.jpg
1e458b5c576ee6b004664c76ae3234c5
893ff4c677251348509233d33d5673c26844e554
37697 F20110112_AAAITU padala_p_Page_60thm.jpg
7d39fad56c0684598e868a9cd08235b6
eac5334b3f1d9a9b64109bb76533ed9753e6d1e5
1959 F20110112_AAAIOX padala_p_Page_47.txt
7ec9dfd959376f6adcad63c39102b058
79cea85ca970c9a7245b8906fd2601d2dbaad586
252392 F20110112_AAAIHC padala_p_Page_01.jp2
6b27aafe2b9bb5ee2d33f7efa796fbbf
7b7a729d8732bcf3cd44a6d41d2e90b1ac0549c5
42334 F20110112_AAAICE padala_p_Page_43.QC.jpg
9bd063e3f6e6e1b56f2bf992af0c0370
18e4071e6407502ff1f688007df265e8b6ec568f
61130 F20110112_AAAITV padala_p_Page_60.QC.jpg
8e4099d5ffc6c6c080e94879c92b34d7
f6890f0a2598abe87f97b580c323fdc79dd54fd3
49651 F20110112_AAAIMA padala_p_Page_26.pro
c165bc4666f1822843527369fba14a75
a52a4d28444ba3c805380bbc6fce536ec2ca1034
1727 F20110112_AAAIOY padala_p_Page_48.txt
1fda190e0b35645f595c5724c8cfb312
00a0a03194c60eeab7284f38d3aca4c9c0f68ed8
30926 F20110112_AAAIHD padala_p_Page_02.jp2
abde98ca4ce8c0b0049c5a3621ed4684
0f685f599cd1208cb7b704ac79d5c54283f310d5
F20110112_AAAICF padala_p_Page_35.tif
80ed750621a1037ac5a7921777885fac
b8792bab1dcc1f8319e38eba5ee94a6a298bb517
64242 F20110112_AAAITW padala_p_Page_62.QC.jpg
b8e8646df196823d31d5aae70f6eda60
4bbd7e437573017ae7586e64c60e08b168021290
2106 F20110112_AAAIOZ padala_p_Page_49.txt
8ebb239de5167ac48b7b9f40dba733c5
503cacbd8100a7b92949025faafd513c74f6f35b
322635 F20110112_AAAIHE padala_p_Page_03.jp2
8b03e249b9c650a0ff2e68f66b1fc657
fb7ff81736bf48e63a59dded6a391eafd18dcd45
631 F20110112_AAAICG padala_p_Page_03.txt
51b25f978e6110ca0390a4db78d87863
4e5fe1adbfcb7c73765bc707db57f86b8ab28707
57523 F20110112_AAAIMB padala_p_Page_27.pro
ecd07af28715a34dab68fda85884e9ee
ebcfb03822d70175ee4537812a6e97a03900d1f3
71151 F20110112_AAAITX padala_p_Page_63.QC.jpg
4a7d556e48636f8d21fb15aa940da388
b8c81ada00fe7e7c1617f2d80048af90c5bcd6d9
1051985 F20110112_AAAIHF padala_p_Page_04.jp2
5265ddc762cc0cc65ba73c036df6866e
39354b517e6eba5ba2431880462464a3da5b8af1
47967 F20110112_AAAICH padala_p_Page_27thm.jpg
52eee89e18f5567e9ebce40ff612a37b
87776317765a194408537213e428ec60a1f8fe9a
49953 F20110112_AAAIMC padala_p_Page_28.pro
a745200a37419f0e8c9e5322f2962b76
3aa618c2836ab7e35c7810da8f124d3b0b706b15
45172 F20110112_AAAITY padala_p_Page_67thm.jpg
bcc395acad24d96a47fdf951ec18455c
01bd141082fe5e716489b66f0d9c0c58b4336ac9
97280 F20110112_AAAIRA padala_p_Page_16.QC.jpg
afdba3fb0717dd4fae8a04668dae01ab
de1df1874aedb8b6ba932a103bbbc56c72ba2b6a
57364 F20110112_AAAICI padala_p_Page_18.pro
c5a725197ba0407b0df2dac22a643fec
f7f0d7703dac7eedad82142116a67549cf0ee5ae
40743 F20110112_AAAIMD padala_p_Page_29.pro
41231b4013809c809d557fb5167c73a1
cc868ef8effd8f4966cb4e04be712804e106982b
101412 F20110112_AAAIRB padala_p_Page_27.QC.jpg
5ec7727d09742207aed22f5c95ce258a
a86dfc1ebec0b7a0ff1446b14e00f4ba12a76aa7
964977 F20110112_AAAIHG padala_p_Page_06.jp2
5432a91bd68b59350c49a1c9be5b10e9
a279daee96cd45bc991c9b36adca28ec185afcaf
223950 F20110112_AAAICJ padala_p_Page_04.jpg
479a9f652fc037efccc04b652033022f
94ff57ca1579f2b575aef197a26a090a9aebceac
41015 F20110112_AAAIME padala_p_Page_30.pro
6c544dfa451c100ffef4db77e2cade9f
570fa5e545960ca7cf226e22672c6b6ff657db15
49204 F20110112_AAAIRC padala_p_Page_03.QC.jpg
0b8d9783e4419f78e31a9f8409d83b30
8461bd92b1c19bc0c339bedacb084a9911ac5abc
965217 F20110112_AAAIHH padala_p_Page_07.jp2
c74de311c0d6ef9e17a6e1c3e91096e5
e1ca4ab806f7596db172d901c8911dd02d36bbe3
37929 F20110112_AAAICK padala_p_Page_61thm.jpg
322dad9a8124945479f94ee3302cb87d
022652305330d778278cb0ee25d73ba8cb16cf3e
48966 F20110112_AAAIMF padala_p_Page_31.pro
2b83017a3c95e3aa543ea279a75f2d91
28a2c0d8a3ad55c3970c9a722ebd288aa68e07ab
32482 F20110112_AAAIRD padala_p_Page_01thm.jpg
b46ef68744892d826ccd32d8094efa45
773155b44c2fb5cf7982e7df1dd1d4c6d25ecbd1
146812 F20110112_AAAIHI padala_p_Page_08.jp2
ea7c1079d6e919df84182362a454945a
fbc0a1d950fcb76a98b679b93a1e606fd963448d
109056 F20110112_AAAICL padala_p_Page_58.jpg
6c6e9f539d40b9854c6ebbb111eeb5d5
d5ab5af5d73d24c8ec4d4ab39142cb6cf96aea93
52212 F20110112_AAAIMG padala_p_Page_32.pro
13c1c7ffc93dc192a24d08effef14a8a
c2cce2031dcd9c3aba51655f5f67e4598a48464d
97539 F20110112_AAAIRE padala_p_Page_65.QC.jpg
eb08fb594f7381e1881ea1830e012911
0c3323f1a75b12c7cd34282bfdf8bda097eb91fa
997915 F20110112_AAAIHJ padala_p_Page_09.jp2
2730cebd637fca5d76aa332ef31a9404
54dd7d42048c5724b9deacdbb16f208d00467c80
934423 F20110112_AAAICM padala_p_Page_44.jp2
9b6cdb3299fbe8cbb83b43bc46e7e34d
51db2f626e2a4280076d7601ad8b9dcd1daff154
20028 F20110112_AAAIMH padala_p_Page_33.pro
e577ab9b894ea5b4295e00757fb1c74c
d65622a77a6f67966affdaafa846974317af589f
47567 F20110112_AAAIRF padala_p_Page_52thm.jpg
1f749525ee174a6b93930f72bff64391
93ba635a60a0fd3de3bdc09098b0fde1d6d8034e
922972 F20110112_AAAIHK padala_p_Page_10.jp2
ae5f64021640c07ee9b78962794bee65
568e366d1fcf4dfc9b7a5299ecac9a2b2e938312
52048 F20110112_AAAICN padala_p_Page_21.pro
2b8d1411d7799e34d48f8c1995626d24
8f48c00b933b0478eab6768b9ff166a011a15602
17474 F20110112_AAAIMI padala_p_Page_34.pro
9e6748fcffe2e419558501a6a257eea3
ae49365cde3a3ac472134b0c745581be6c3423e2
103974 F20110112_AAAIRG UFE0002826_00001.xml
19427ae3557c38956c06a5a3fc72999e
79561ac4fb14776b6198ff7a23c249ff24f13f5b
839186 F20110112_AAAIHL padala_p_Page_11.jp2
c65d8141fb576f1b62913906ee6b03cd
749c0372a5304f1d8e74d2c428bb8637f6069d91
204734 F20110112_AAAICO padala_p_Page_43.jp2
be51500a853b16c57e9a19e9e9958242
dfd1ce9e332b20f1cf42d0cb247acffbb6ef37c2
19329 F20110112_AAAIMJ padala_p_Page_36.pro
b8c935feedf8221858acb39668f73bae
625cc8270435ebb667831dd2a9e0f28d42bfc209
45241 F20110112_AAAIRH padala_p_Page_01.QC.jpg
6c2d72951f5d8cabf85d72e68d560074
9bab140ae2e1900fa1318f4ff1e035f28cd9e314
1051975 F20110112_AAAIHM padala_p_Page_12.jp2
43436a21427e426c1ae0a7b0981ecc2c
c8588b5a3a9e461d6b896dc81b7ad9a84de30fa9
2054 F20110112_AAAICP padala_p_Page_05.txt
90a1a43e5b441ee95dd3113131f168b3
0a9f1606306464924af6c67f608562e123f90c93
47538 F20110112_AAAIMK padala_p_Page_37.pro
a9952f2d431fb6bb3041466bc21db5ee
eb41d43436ac169b7c18722d30c8e3946bba7773
28365 F20110112_AAAIRI padala_p_Page_02thm.jpg
e965b8cbd1ca24163edd7ca60484ea1d
be826a9f179218200a5661e70b8b23137b366c53
1051980 F20110112_AAAIHN padala_p_Page_14.jp2
a241bace881b46579afcd49a588a1299
c0208cce3d898efd728f2dceb05e1f156a065164
147866 F20110112_AAAICQ padala_p_Page_63.jpg
4051d2599b41a2bd3ef300b4dcdf4209
bcda6eca03c98a434519d0c275fd6dc766ef18b1
89646 F20110112_AAAIRJ padala_p_Page_04.QC.jpg
5b44bba491765decc447d2dcd62a2ef8
733b8a8b4805be277e9653c9a453b6ee03327b81
891605 F20110112_AAAIHO padala_p_Page_15.jp2
8377b62695beb63c4dd566afdd6d8fa3
ce98a84ea40db4e40ef7f5d7ecfda827d920ec4f
44466 F20110112_AAAICR padala_p_Page_09.pro
51439528e77f4d0283e977b1d14f33b3
579358ca56a2f295e59245ad36da02e2b640f763
29480 F20110112_AAAIML padala_p_Page_38.pro
9eeccd1e26aa6549d6c0f6f1c9d088c2
1c1ac413d827eb2442ad2136e424fa7171efa8d5
45593 F20110112_AAAIRK padala_p_Page_07thm.jpg
3377bc848b45d725a5ef8af2a68aa178
90d393f7ef2f39e623e6b8500f29072f224b9b23
1051956 F20110112_AAAIHP padala_p_Page_16.jp2
dbc04d3ed3ec0d7a8a38096d70eb85bd
c3b4169d1d06165f24bb61ab1a382b12bc6f51f9
F20110112_AAAICS padala_p_Page_05.jp2
a514db2467f058e1d24b5f8db4887a72
20c0642ee24141f39a243ced36a8a3f4f038c276
42181 F20110112_AAAIMM padala_p_Page_39.pro
2a111ae8f4bc3deb65ecc2dfebbe13aa
3b08de52d1e8c41e498c8cd6226051827b0bfe70
89617 F20110112_AAAIRL padala_p_Page_07.QC.jpg
430cbb5369b9e84c30ca67791611c3f6
df2e242d12f9e0ce307d420e14c632f1069bcdd9
1051911 F20110112_AAAIHQ padala_p_Page_17.jp2
2009bc918b17ca1bc3b91d03e500f6e4
b3fc4607c0f577d9d3974db3e92fe3b7b2053179
73917 F20110112_AAAICT padala_p_Page_06.QC.jpg
34ff17fc0705e7db71c7fced716caf70
affa9096c45866bcf0ffb0ffe087d6a08cd57092
20085 F20110112_AAAIMN padala_p_Page_40.pro
65de9ed1bc2b96975367604d13c0847d
36bb24bf3f1cb845c715003313001b5465584dfe
30904 F20110112_AAAIRM padala_p_Page_08thm.jpg
eeb1feca539f4482eb8f3490ff587318
368b21f31d56d30533964ce014d09dc805381eaf
1051950 F20110112_AAAIHR padala_p_Page_18.jp2
0764ec17664618ac6377d21b54fea248
eb759e6075e01e6696997e7de1be1ee62ee3b408
215599 F20110112_AAAICU padala_p_Page_47.jpg
866c2a155005abf3a66ad147179b4128
6881c78c8790e77ae5130a6b07b66f493febb55a
33413 F20110112_AAAIMO padala_p_Page_41.pro
08f4a107db1458d3b88564c3ae976ace
cb4ea0f61b6d9a81a80b814045dfa283aa921ea4
37560 F20110112_AAAIRN padala_p_Page_08.QC.jpg
bb085d293ddafd6a25aca0aa18376782
b43ab415233345e54f442ebf6b3723e75eb98380
1051963 F20110112_AAAIHS padala_p_Page_20.jp2
ea3c70b2e4247b2011f7ba02b49201fb
ee1f74e320f7cd2adfb25318db2665769ddc5d0c
F20110112_AAAICV padala_p_Page_56.tif
7aae5adceadbaf5ab4ad3e6de11e9194
f1e6b84593247fae515d8f62ba3740fd66eb0b5f
13818 F20110112_AAAIMP padala_p_Page_42.pro
6915120871db5ca85e1fefa7d4b668b7
0959aa22953a0bd79462b0050624e17bd696802c
45647 F20110112_AAAIRO padala_p_Page_09thm.jpg
b8fcfb9454f47e523997a20f20930a87
ce40a2d343cd910fe805e38c06b7cc89109f83e9
213709 F20110112_AAAIHT padala_p_Page_22.jp2
d52376fb18f37218e69f934a725f1db6
616fe1455ee447076d5d76a7d523bbf45f5a2e4e
35952 F20110112_AAAICW padala_p_Page_36thm.jpg
9c9e241b0e0e985d47ff2c6425d136cb
db3fd9105165a84dcf4b8a78ce52bc8db10a6076
41895 F20110112_AAAIMQ padala_p_Page_44.pro
3883bf8d92565eaa487ed91b850b5d79
641ee3a53fe6331bd4657427b178cc8a0b895aad
92448 F20110112_AAAIRP padala_p_Page_09.QC.jpg
faec2b5f070f37fee6a6fc69bfdfb3e6
86aea20062fec129c8dcec6058dc6675ad4b8cbd
1051949 F20110112_AAAIHU padala_p_Page_23.jp2
e4e911e4eb65c49205acd6cfbb69850d
2d35163d3182a14d4cc9f6c8221f260bde632063
49389 F20110112_AAAICX padala_p_Page_51thm.jpg
14cb7bc03dababc60883e7c24ae49a2c
ee7176011151b37879b53d85ce1ea04ad28bb0e5
33433 F20110112_AAAIMR padala_p_Page_48.pro
f79cdbadca79dbef2da15170d0fbbf7e
0f10a8e6cbcd756f5453e2ee1f0346a57647a633
831000 F20110112_AAAIHV padala_p_Page_24.jp2
3ca077e3438bf60e11d2a789c415aea6
44734db716636c5c718699cbcaf4d51c19d52b32
629333 F20110112_AAAICY padala_p_Page_38.jp2
d126dbe5b7da8e6636c25ac696898476
03382c37c92c0a7a8d96ee141d715d8dcc678e32
51555 F20110112_AAAIMS padala_p_Page_49.pro
3ac1b8925789bab5e776241301517e4a
abbf50ec5b841aab7d100d596ae95cf9cb21ecb8
89185 F20110112_AAAIRQ padala_p_Page_10.QC.jpg
f0ac5ade282d45684a5e8b69e5446aba
ec105ebad5e45b6da8ffd1d2c8a8c3a8ac2d27e6
1051921 F20110112_AAAIHW padala_p_Page_25.jp2
8bbdcc47fef9295f9f9a43d88cf2b723
357d38afd7fa4f345135b41b0b62725c7afdb313
49944 F20110112_AAAICZ padala_p_Page_66thm.jpg
813b920293fa08a002d778bc0d56a5d1
96088dd5da351ee8af83e5a4efec72f73246c227
40483 F20110112_AAAIMT padala_p_Page_50.pro
4ee8baf5e7c90417378a22fc02d23996
8b6fcf246014a93473a0879a4befeb1f745d4861
82246 F20110112_AAAIRR padala_p_Page_11.QC.jpg
74205d40f0f34f43f6233e5fa714ffec
e70457748f0a22cb89269a8e063efa8b8b777f1c
1051979 F20110112_AAAIHX padala_p_Page_26.jp2
a75e46383d8df4d616a4770fb9d7f930
88b44e44ab72999a552d7abea6d7d38036e62ab1
61537 F20110112_AAAIMU padala_p_Page_51.pro
e7d7f73ff84782c39c46fd54d355abb9
7f40a3578fdf8cc6e98b39718d68271b541a9fee
48969 F20110112_AAAIRS padala_p_Page_12thm.jpg
f61ffd4cecce87016f47709c38ab583a
fdf1bb1f3e47ba82278c4b6c25c89bab5145fcaa
1051954 F20110112_AAAIHY padala_p_Page_28.jp2
449149fbd5112e526f8fce5e62b53d94
000f15dfacf1426aa402d8670f10c13104e785c4
48422 F20110112_AAAIMV padala_p_Page_52.pro
9d3ae52d64e9e2581af4e3b154f05d22
95e7414dfab2aff4b6619478439657f74133a586
39192 F20110112_AAAIFA padala_p_Page_02.jpg
1e2d2ee79bf6a10aca539cbc99aec5f6
c45567bccc158508df194fe6e372d74edcd659e8
105549 F20110112_AAAIRT padala_p_Page_12.QC.jpg
58b39a10dede6b4aaafc1aa9def974ce
c012e382e3c572ad6627757ebd9a70158e247c0b
898630 F20110112_AAAIHZ padala_p_Page_29.jp2
f4f1cc7106a16b7db1ff910060f66c51
68e817c866030e168d6aaffff82ec2f23bea83fb
40716 F20110112_AAAIMW padala_p_Page_53.pro
b27066b8c2219c0519487d8855e104ba
f64eeb11195df1a9ca1b220104eb1daf281a69cb
254588 F20110112_AAAIFB padala_p_Page_05.jpg
079ea1d48121f37aef9b231cda122c11
31d0a27706725c8d45347c90353e73297f2328a8
102371 F20110112_AAAIRU padala_p_Page_14.QC.jpg
d51fd34c1193a5063e35d80504656db7
7fae1b21c0d20ec3b73c49ade2ad3658dc8799b1
44683 F20110112_AAAIMX padala_p_Page_54.pro
62c6d3a76eab2340788fcfd034d5da0a
dee64565f4bcb740c0209cd343a7a096ded70b6c
211853 F20110112_AAAIFC padala_p_Page_07.jpg
27022e9c2130c06068116d24b9dcd150
70a54294dc719de807e5b244929be8c03ffaa565
45840 F20110112_AAAIRV padala_p_Page_15thm.jpg
5f49d51ac49ad611a742a6c305c29247
1ae92256fac6dd14934e90eb68023342238c9144
F20110112_AAAIKA padala_p_Page_27.tif
57173d47a780ed716b85c16ef9daef19
1394a123d1ff884d43ae020ae2fae42a4fb33dd4
32784 F20110112_AAAIMY padala_p_Page_56.pro
1b4a6c4e0b1631f3eb73c1b49547ec0a
956c3f94ebb013d5ff4f86d2a0263b4a4664fca3
206483 F20110112_AAAIFD padala_p_Page_09.jpg
1ee8a384b1ead67b3f5e5a74115e9bac
0d8a28ced6545a41b46bb83939d317d90b7b0520
46869 F20110112_AAAIRW padala_p_Page_16thm.jpg
00dd8137021668a4e3e2bbc3f47da05e
4f6c05c2b4a9fc2e04a08d3bf674a938e3c7fb44
F20110112_AAAIKB padala_p_Page_29.tif
a45fc03316b3e9cec006c2f6d6300599
0594ba89bf4cfb3af63f781591b8e4a150839b08
26929 F20110112_AAAIMZ padala_p_Page_57.pro
5b470bd18a89ddcb3b49f03c1835d536
045e7dedc756dc0143df4b1b624cf884c5e743bf
45971 F20110112_AAAIRX padala_p_Page_17thm.jpg
779cc4cadc0e208efe535013add2c9e7
57a961e311e1766c9542036588ca5fd042ebd717
F20110112_AAAIKC padala_p_Page_30.tif
d1477ee4442741c04e23a98355ee3849
35222f74b214fb45f219ca90ba368c91069a7c16
197693 F20110112_AAAIFE padala_p_Page_10.jpg
a7b42becce52e71301aeb01dcb1e842b
fa4f74b97d412285dc4e11c0039b3d4060efb96b
93787 F20110112_AAAIRY padala_p_Page_17.QC.jpg
4137784cf69e47b53b2225966462362b
04a17c7ef8c7c655842c520b75fc5de613381924
F20110112_AAAIKD padala_p_Page_31.tif
a19d302a52a3d4ef456a7d15c956efae
4fd48fec70bda82ac6f5b9739a64d7d339580b4a
270216 F20110112_AAAIFF padala_p_Page_12.jpg
25f5d9c8cccb4e1be17b09eb84626bbd
70955431b84ff0975ab22df041c2c20a5eae37ba
1842 F20110112_AAAIPA padala_p_Page_50.txt
805cc2fc8b5b05a8ba3bcc3f176c5d94
ba8a28bf7618db72d47c2aca7afc90d11f14f336



PAGE 1

DESIGN AND IMPLEMENT A TION OF GRIDOS: OPERA TING SYSTEM SER VICES F OR GRID AR CHITECTURES By PRADEEP P AD ALA A THESIS PRESENTED TO THE GRADUA TE SCHOOL OF THE UNIVERSITY OF FLORID A IN P AR TIAL FULFILLMENT OF THE REQUIREMENTS F OR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORID A 2003

PAGE 2

Cop yrigh t 2003 b y Pradeep P adala

PAGE 3

A CKNO WLEDGMENTS I w ould lik e to gratefully ac kno wledge the great sup ervision of Dr. Joseph Wilson during this w ork. I thank Dr. Mic hael F rank and Dr. P aul Av ery for serving on m y committee and for reviewing m y w ork. I also w ould lik e to thank Dr. Ric hard Ca v annaugh and Dr. Sanja y Rank a for their helpful suggestions in grid le system w ork. I am grateful to all m y friends who help ed directly or indirectly in preparing this w ork. Finally I am forev er indebted to m y paren ts for helping me to reac h this stage in m y life. iii

PAGE 4

T ABLE OF CONTENTS page A CKNO WLEDGMENTS . . . . . . . . . . . . . . iii LIST OF FIGURES . . . . . . . . . . . . . . . . vi ABSTRA CT . . . . . . . . . . . . . . . . . . vii 1 INTR ODUCTION . . . . . . . . . . . . . . . 1 2 MOTIV A TION . . . . . . . . . . . . . . . . 3 2.1 The Grid . . . . . . . . . . . . . . . . 3 2.2 Grid Applications . . . . . . . . . . . . . 4 2.3 Grid Middlew are . . . . . . . . . . . . . 5 2.4 Globus . . . . . . . . . . . . . . . . 6 2.4.1 Securit y . . . . . . . . . . . . . . 8 2.4.2 Data Managemen t . . . . . . . . . . . 8 2.4.3 Resource Managemen t . . . . . . . . . . 9 2.4.4 Information Services . . . . . . . . . . . 9 2.5 Condor . . . . . . . . . . . . . . . . 10 2.6 Legion . . . . . . . . . . . . . . . . 12 2.7 Previous W ork . . . . . . . . . . . . . . 12 3 GRIDOS DESIGN . . . . . . . . . . . . . . . 15 3.1 Core Principles . . . . . . . . . . . . . . 15 3.2 Core Mo dules . . . . . . . . . . . . . . 16 3.2.1 gridos io: High-P erformance I/O Mo dule . . . . . 17 3.2.2 gridos comm: Comm unication Mo dule . . . . . . 18 3.2.3 gridos rm: Resource Managemen t Mo dule . . . . . 20 3.2.4 gridos pm: Pro cess Managemen t Mo dule . . . . . 20 3.3 Additional Mo dules . . . . . . . . . . . . . 21 3.3.1 gridos ftp common . . . . . . . . . . . 21 3.3.2 gridos ftp serv er . . . . . . . . . . . . 21 3.3.3 gridos ftp clien t . . . . . . . . . . . . 21 4 IMPLEMENT A TION . . . . . . . . . . . . . . 22 4.1 Lin ux Kernel Mo dule Arc hitecture . . . . . . . . . 22 4.2 Kernel Lev el W eb/Ftp Serv er (tux) . . . . . . . . 23 4.2.1 User Lev el Access to k ernel HTTP la y er . . . . . 24 iv

PAGE 5

4.2.2 Listening & Accepting Messages . . . . . . . 24 4.3 Mo dules . . . . . . . . . . . . . . . . 29 4.3.1 Activ ation . . . . . . . . . . . . . 29 4.3.2 IO Mo dule . . . . . . . . . . . . . 29 4.3.3 FTP Clien t and Serv er Mo dules . . . . . . . 31 4.4 Library W rapp er . . . . . . . . . . . . . 31 4.5 GridOS Middlew are . . . . . . . . . . . . . 32 5 SCENARIOS . . . . . . . . . . . . . . . . 33 5.1 Scenario #1: T ransp orting a le . . . . . . . . . 33 5.2 Scenario #2: Reading and W riting to a le lo cally . . . . 33 6 PERF ORMANCE . . . . . . . . . . . . . . . 36 6.1 T est En vironmen t and Metho dology . . . . . . . . 36 6.2 GridOS vs Proftp d . . . . . . . . . . . . . 37 6.3 GridFTP vs GridOS ftp serv er using globus-url-copy clien t . 38 6.4 GridFTP serv er/clien t vs GridOS ftp serv er/clien t . . . . 38 7 GRID FILE SYSTEM . . . . . . . . . . . . . . 39 7.1 Motiv ating Example . . . . . . . . . . . . 40 7.2 Requiremen ts . . . . . . . . . . . . . . 43 7.3 Design . . . . . . . . . . . . . . . . 44 7.3.1 Logical Hierarc hical Name Space . . . . . . . 44 7.3.2 Data Access/T ransfer and Replica Managemen t . . . 44 7.3.3 POSIX seman tics . . . . . . . . . . . 44 7.3.4 Metadata . . . . . . . . . . . . . . 46 7.3.5 Automatic Data Managemen t . . . . . . . . 46 7.3.6 P erformance Optimization . . . . . . . . . 46 7.4 Building the Service . . . . . . . . . . . . . 47 7.4.1 ServiceData . . . . . . . . . . . . . 47 7.4.2 Notication . . . . . . . . . . . . . 48 7.5 Op en Questions . . . . . . . . . . . . . . 48 8 FUTURE W ORK . . . . . . . . . . . . . . . 49 9 CONCLUSIONS . . . . . . . . . . . . . . . 50 APPENDIX Grid File System GWSDL Description . . . . . . . 51 REFERENCES . . . . . . . . . . . . . . . . . 57 BIOGRAPHICAL SKETCH . . . . . . . . . . . . . . 60 v

PAGE 6

LIST OF FIGURES Figure page 2{1 La y ered grid arc hitecture . . . . . . . . . . . . 7 2{2 A ClassAd example . . . . . . . . . . . . . . 11 3{1 Ma jor mo dules and structure of GridOS . . . . . . . . 16 4{1 T ux actions . . . . . . . . . . . . . . . . 25 4{2 Connection accept . . . . . . . . . . . . . . 26 4{3 Ev en t lo op . . . . . . . . . . . . . . . . 27 4{4 Accept request . . . . . . . . . . . . . . . 28 4{5 File write function listing . . . . . . . . . . . . 30 5{1 T ransp orting a le using GridOS . . . . . . . . . . 34 5{2 T ransp orting a le using normal FTP clien t and serv er . . . . 34 5{3 Reading and writing to a le . . . . . . . . . . . 35 6{1 GridOS vs Proftp d using standard ftp clien t . . . . . . . 37 6{2 GridOS ftp vs GridFTP using globus-url-cop y as clien t . . . . 37 6{3 GridOS ftp serv er/clien t vs GridFTP serv er/globus-url-cop y . . 38 7{1 ur.edu logical structure . . . . . . . . . . . . . 40 7{2 ucsd.edu logical structure . . . . . . . . . . . . 40 7{3 Find query result . . . . . . . . . . . . . . 42 7{4 FSS arc hitecture . . . . . . . . . . . . . . . 45 vi

PAGE 7

Abstract of Thesis Presen ted to the Graduate Sc ho ol of the Univ ersit y of Florida in P artial F ulllmen t of the Requiremen ts for the Degree of Master of Science DESIGN AND IMPLEMENT A TION OF GRIDOS: OPERA TING SYSTEM SER VICES F OR GRID AR CHITECTURES By Pradeep P adala Decem b er 2003 Chair: Joseph N. Wilson Ma jor Departmen t: Computer and Information Science and Engineering In this w ork, w e demonstrate the p o w er of pro viding a common set of operating system services to grid arc hitectures, including high-p erformance I/O, comm unication, resource managemen t and pro cess managemen t. A grid enables the sharing, selection, and aggregation of a wide v ariet y of geographically distributed resources including sup ercomputers, storage systems, data sources, and sp ecialized devices o wned b y dieren t organizations administered with dieren t p olicies. In the last few y ears, a n um b er of exciting pro jects lik e Globus, Legion, and UNICORE dev elop ed the soft w are infrastructure needed for grid computing. Ho w ev er, op erating system supp ort for grid computing is minimal or non-existen t. T o ol writers are forced to re-in v en t the wheel b y implemen ting from scratc h. This is error prone and often results in sub-optimal solutions. W e ha v e dev elop ed GridOS, a set of op erating system services that faciliate grid computing. These services, dev elop ed as k ernel mo dules mak e a normal commo dit y op erating system lik e Lin ux highly suitable for grid computing. The mo dules are designed to b e p olicy neutral, exploit commonalit y in v arious grid infrastructures and pro vide high-p erformance. Our vii

PAGE 8

exp erimen ts with GridOS v erify that there is dramatic impro v emen t in p erformance when compared to the existing grid le transfer proto cols lik e GridFTP W e ha v e also dev elop ed a pro of-of-concept middlew are using GridOS. viii

PAGE 9

CHAPTER 1 INTR ODUCTION A grid[ 1 ] enables the sharing, selection, and aggregation of a wide v ariet y of geographically distributed resources including sup ercomputers, storage systems, data sources and sp ecialized devices o wned b y dieren t organizations administered with dieren t p olicies. Grids are t ypically used for solving large-scale resource and computing in tensiv e problems in science, engineering, and commerce. In the last few y ears, a n um b er of exciting pro jects lik e Globus[ 2 ], Legion[ 3 ] and UNICORE[ 4 ], dev elop ed the soft w are infrastructure needed for grid computing. V arious distributed computing problems ha v e b een solv ed using these to ols and libraries. Ho w ev er, op erating system supp ort for grid computing is minimal or non-existen t. Though these to ols ha v e b een dev elop ed with dieren t goals, they use a common set of services pro vided b y the existing op erating system to ac hiev e dieren t abstractions. GridOS pro vides op erating system services that supp ort grid computing. It mak es writing middlew are easier and pro vides services that mak e a normal commo dit y op erating system lik e Lin ux more suitable for grid computing. The services are designed as a set of k ernel mo dules that can b e inserted and remo v ed with ease. The mo dules pro vide mec hanisms for high p erformance I/O (gridos io), comm unication (gridos comm), resource managemen t (gridos rm), and pro cess managemen t (gridos pm). These mo dules are designed to b e p olicy neutral, easy to use, consisten t and clean. The goal of this b o dy of w ork is to demonstrate the p o w er of op erating system services sp ecic to grid computing. W ell designed minimal, p olicy-neutral op erating 1

PAGE 10

2 system services can mak e a commo dit y lin ux op erating system highly suitable for grid computing. In c hapter 2 w e describ e the motiv ation b ehind this w ork. Details of previous w ork and an o v erview of curren t trends are pro vided. A clean design pla ys an imp ortan t role in adding rexible and p o w erful services to an existing op erating system. Chapter 3 giv es a detailed descripting of our design pro cess. Our design priniciples and motiv ation b ehind c ho osing a la y ered arc hitecture are explained. GridOS consists of four core mo dules including high p erformance i/o, resource managemen t, pro cess managemen t and comm unication. Design considerations for eac h mo dule are detailed. Chapter 4 pro vides details of implemen tation. W e dev elop ed the mo dules as k ernel mo dules using Lin ux 2.4.19 k ernel. Lin ux k ernel mo dule arc hitecture is exploited to pro vide easy loading and unloading of the mo dule. Sp ecic details on implemen ting the ftp mo dules with details on mo dule activ ation and de-activ ation are pro vided. W e also dev elop ed middlew are to ease the pro cess of writing an application that uses GridOS services. Chapter 5 sho ws v arious scenarios of GridOS usage. The c hapter giv es a pictorial view of GridOS op erations. Our exp erimen ts indicate that GridOS outp erforms the standard ftp and GridFTP Details ab out the exp erimen ts and graphs sho wing p erformance comparison of GridOS with basic FTP and GridFTP are in c hapter 6 W e conclude with p ossible ideas for future w ork and impro v emen ts that can b e done to GridOS.

PAGE 11

CHAPTER 2 MOTIV A TION This c hapter presen ts the motiv ation b ehind this thesis. It pro vides an o v erview of grid computing and curren t trends in grid computing. The most prominen t grid middlew are Globus and Condor are explained briery 2.1 The Grid Distributed computing has fascinated researc hers all o v er the w orld for past t w o decades. T raditionally the fo cus has b een on dev eloping a unied homogeneous distributed system. Recen tly there has b een tremendous gro wth in wide area distributed computing leading to grid computing[ 1 ]. The term Grid is c hosen as an analogy to electric p o w er grid that pro vides consisten t, p erv asiv e, dep endable, transparen t access to electricit y irresp ecitv e of t yp e and lo cation of source. The primary fo cus in Grid computing is to harness the p o w er of geographically distan t sup ercomputers, and con v ert them in to a big computing resource. The Grid enables sharing, selection and aggregation of v arious resources including ra w cpu cycles, storage systems, data sources and sp ecial services lik e application serv ers, etc. These resources ma y b e geographically disp ersed, op erated b y dieren t organizations with dieren t p olicies running on completely dieren t op erating systems. Due to the recen t explosion of Grid T ec hnologies, there has b een some confusion o v er the exact nature of a Grid. Dr. F oster pro vides a three p oin t c hec klist[ 5 ] for ev aluating grid systems. 3

PAGE 12

4 A grid is a system that co ordinates resources that are not sub ject to cen tralized con trol A Grid in tegrates and co ordinates resources and users that liv e within dieren t con trol domains for example, the user's desktop vs. cen tral computing; dieren t administrativ e units of the same compan y; or dieren t companies; and addresses the issues of securit y p olicy pa ymen t, mem b ership, and so forth that arise in these settings. Otherwise, w e are dealing with a lo cal managemen t system. uses standard, op en, general-purp ose proto cols and in terfaces A Grid is built from m ulti-purp ose proto cols and in terfaces that address suc h fundamen tal issues as authen tication, authorization, resource disco v ery and resource access. It is imp ortan t that these proto cols and in terfaces b e standard and op en. Otherwise, w e are dealing with an application-sp ecic system. deliv ers non trivial qualities of service A Grid allo ws its constituen t resources to b e used in a co ordinated fashion to deliv er v arious qualities of service, relating for example to resp onse time, throughput, a v ailabilit y and securit y and/or co-allo cation of m ultiple resource t yp es to meet complex user demands, so that the utilit y of the com bined system is signican tly greater than that of the sum of its parts. Grids are comp osed of V O( Virtual Or ganization )s, a conglomeration of net w ork resources consisting of serv ers, desktop PCs, mainframes, clusters, etc. These V Os are managed b y dieren t organizations and ma y ha v e dieren t p olicies and securit y mec hanisms. Grid enables sharing of resources b et w een these heterogeneous V Os with a common set of op en proto cols. There are enormous opp ortunities for application writers to exploit the large amoun t of computational and storage resource pro vided b y the grid. 2.2 Grid Applications Grid applications t yp cially in v olv e large-scale scien tic computing that requires h uge amoun t of cpu and data pro cessing resources. The Grid Computing paradigm allo ws these h uge applications to run smo othly There are three classes of applications: compute in tensiv e, data in tensiv e and mixed applications. Compute in tensiv e applications suc h as nite elemen t analysis, computational ruid dynamics, and design-of-exp erimen t (DOE) sim ulations often require a large

PAGE 13

5 amoun t of CPU p o w er. These applications can easily b e parallelized and can b e run on the grid. Data in tensiv e applications require large inputs and pro duce h uge amoun ts of data (sometimes on the order of p etab ytes). V arious scien tic applications, including High Energy Ph ysics(HEP), Biology and Medical and Earth Observ ations(EO) applications, analyze and deriv e large amoun ts of data. There is also a gro wing need to share this data among v arious scien tic comm uinities. The comm unities of researc hers are often large and geographically distributed, as are the computing and storage resources used to analyze the data. The data grid [ 6 ] pro vides a w a y of managing this distributed data in a seamless w a y Some applications are b oth compute and data in tensiv e. 2.3 Grid Middlew are T o ac hiev e the goals of the Grid, existing tec hnologies are extended and v arious new tec hnologies are dev elop ed. These tec hnologies pro vide a framew ork to do v arious Grid op erations with minim um in teraction with underlying platform, arc hitecture and op erating system. Grid middlew are pro vides facilities to use the grid for applications and users. Middlew are lik e Globus[ 2 ], Legion[ 3 ] and UNICORE[ 4 ] pro vide soft w are infrastructure to tac kle v arious c hallenges of computational and data grids. Data midd lewar e whic h usually is part of general purp ose grid middlew are, pro vides facilities for data managemen t. V arious middlew are pro ducts ha v e b een dev elop ed in recen t y ears that are widely in v arious scenarios. In their earlier v ersions, grid middlew are pro vided incompatible metho ds to access, manipulate and store the data. The Op en Grid Services Arc hitecture(OGSA)[ 7 ] denes the standard comm unication proto cols and formats for building truly in terop erable grid systems. The Op en Grid Services Infrastructure(OGSI)[ 8 ] pro vides the sp ecication for building v arious grid services

PAGE 14

6 en visioned in OGSA. These sp ecications ha v e standardized grid services describing ho w they op erate and in teract. OGSI pro vides detailed WSDL sp ecications for standard in terfaces that dene a grid service. The third v ersion of the Globus to olkit (GT3) pro vides implemen tation of OGSI sp ecication and pro vides v arious OGSI-complian t basic services including managed job service, index service and reliable le transfer service (RFT). GT3 also pro vides higher lev el data services including RLS (Replica Lo cation Service). The data managemen t services RFT and RLS pro vide the basic mec hanisms for data managemen t. In the follo wing sections, w e explore p opular grid middlew are pro ducts and their arc hitectures. 2.4 Globus Globus[ 2 ] pro vides a soft w are infrastructure that enables applications to handle distributed heterogeneous computing resources as a single virtual mac hine. The Globus pro ject is a U.S. m ulti-institutional researc h eort that seeks to enable the construction of computational Grids. A computational Grid, in this con text, is a hardw are and soft w are infrastructure that pro vides dep endable, consisten t, and p erv asiv e access to highend computational capabilities, despite the geographical distribution of b oth resources and users. Globus pro vides basic services and capabilities that are required to construct a computational Grid. The to olkit consists of a set of comp onen ts that implemen t basic services, suc h as securit y resource lo cation, resource managemen t, and comm unications. It is necessary for computational Grids to supp ort a wide v ariet y of applications and programming paradigms. Consequen tly rather than pro viding a uniform programming mo del, suc h as the ob ject-orien ted mo del or message-passing mo del, the Globus pro vides a bag of services from whic h dev elop ers of sp ecic to ols or applications can use to meet their o wn particular needs. This metho dology is only

PAGE 15

7 p ossible when the services are distinct and ha v e w ell-dened in terfaces (APIs) that can b e incorp orated in to applications or to ols in an incremen tal fashion. Globus is constructed as a la y ered arc hitecture in whic h high-lev el global services are built up on essen tial lo w-lev el, core lo cal services. The Globus to olkit is mo dular and an application can exploit Globus features, suc h as resource managemen t or information infrastructure without using Globus comm unication libraries. Before w e try to understand the Globus arc hitecture, let us ha v e a quic k lo ok at the la y ered grid arc hitecture. Figure 2{1 sho ws the la y ered structure of the grid arc hitecture. Grid Applications TCP Condor globus-url-copy GridFTP High Level Grid ServicesLow Level Grid ServicesLocal Services Figure 2{1: La y ered grid arc hitecture As w e can see, the applications can use high-lev el to ols lik e globus-url-copy or use the lo w lev el libraries lik e globus ftp client The Globus to olkit is divided in to three pillars. Eac h pillar represen ts a primary comp onen t that addresses v arious asp ects of grid computing. All the comp onen ts use GSI (Grid Securit y Infrastructure)[ 9 ] for securit y at the connection la y er. Eac h of these comp onen ts has a primary proto col pro viding the basic functionalit y GRAM (Globus Resource Allo cation Manager)[ 10 ] implemen ts a resource managemen t proto col, MDS (Metacomputing Directory Service)[ 11 ] implemen ts an information services proto col, and GridFTP[ 12 ] implemen ts a data transfer proto col.

PAGE 16

8 2.4.1 Securit y GSI pro vides a securit y framew ork for Globus. All other comp onen ts use this la y er to connect to the w orld. It pro vides v arious features whic h are imp ortan t and necessary in a grid en vironmen t Se cur e authentic ation and authorization : GSI pro vides features to securely authen ticate a user and authorize access to resources Single sign-on : One of the problems asso ciated with distributed systems is the task of authen ticating a user on eac h system that he/she w an ts to execute a task. GSI pro vides single sign-on using whic h a user has to authen ticate only once and his pro xy can execute tasks in v arious administrativ e domains. The pro xies ha v e a limited lifetime to a v oid compromise of creden tials. Inter op er ability with lo c al se curity solutions : Usually V Os ha v e dieren t lo cal securit y p olicies within their domain. GSI pro vides mec hanisms to translate b et w een in ter domain securit y op erations and lo cal mec hanisms. Uniform cr e dentials/c ertic ation : GSI uses X.509 certicate data format and public k ey encryption for user creden tials. Users ha v e to obtain a certicate to access Globus resources. 2.4.2 Data Managemen t In scien tic exp erimen ts, ecien t data managemen t pla ys an imp ortan t role. These applications access and analyze large amoun ts of data (sometimes of the order of p eta b ytes) and require high-p erformance and reliable data transfers. Globus pro vides GridFTP a high-p erformance, secure, and reliable data transfer proto col optimized for high-bandwidth wide-area net w orks. GridFTP extends the p opular FTP with features lik e m ultiple TCP streams, strip ed data transfers, etc. Some of the features are Se cur e data tr ansfer : GridFTP uses GSI to pro vide secure data transfer mec hanisms Par al lel data tr ansfer : Multiple TCP streams are used to ecien tly utilize the high bandwidth of wide-area net w orks. Partial data tr ansfer Thir d p arty data tr ansfer : Data can b e transferred from a serv er to another serv er using third part y con trol.

PAGE 17

9 Strip e d data tr ansfer : This is an imp ortan t feature whic h allo ws data to b e partitioned across m ultiple serv ers. As a result, with ecien t data partitions, aggregate bandwidth can b e greatly impro v ed. 2.4.3 Resource Managemen t Resource managemen t is an imp ortan t comp onen t of a grid. Globus pro vides features to allo cate and use resources. Resource managemen t comp onen t consists of three main comp onen ts RSL (R esour c e Sp e cic ation L anguage) : RSL pro vides a common language used b y all the comp onen ts in resource managemen t arc hitecture to p erform their functions. A user uses RSL to sp ecify resource requiremen ts, e.g. executable = globus-url-copy GRAM (Globus R esour c e A l lo c ation Manager) : GRAM manages allo cation of resources for execution of jobs. It pro vides a standard in terface to lo cal resource managemen t to ols lik e LSF, Condor etc. Users can query GRAM to get the status of their submitted jobs. DUR OC (Dynamic al ly Up date d R e quest Online Co-al lo c ator) : Co-allo cation is the pro cess of allo cating m ultiple resources at v arious sites required b y grid applications. This is an imp ortan t asp ect of grid computation. DUR OC pro vides an API to allo cate resources in m ultiple sites. 2.4.4 Information Services The Globus information service is called Metacomputing Directory Service(MDS). It pro vides means of disco v ering, c haracterizing and monitoring resources and services in a heterogeneous en vironmen t. MDS uses LD AP for pro viding uniform access. MDS has t w o main comp onen ts GRIS (Grid R esour c e Information Servic e) : GRIS pro vides uniform means of querying resources for their curren t conguration, capabilities, and status. This is used b y GRAM to pro vide status of jobs to the user. GIIS (Grid Index Information Servic e) : GI IS can b e used to disco v er resources matc hing a criterion. It pro vides a coheren t system image of the grid that can b e explored b y applications.

PAGE 18

10 Globus can b e though t of as a Grid computing framew ork based on a set of APIs to the underlying services. Globus pro vides application dev elop ers with v arious means of implemen ting a range of services to pro vide a wide-area application execution en vironmen t. 2.5 Condor The Condor[ 13 ] pro ject started as pro viding a framew ork for high throughput computing. It pro vides a framew ork for w orkload managemen t in a p o ol of w ork stations. Condor allo ws eectiv e utilization of a v ailable cpu cycles b y detecting idle w orkstations. Condor pro vides a job queueing mec hanism, sc heduling p olicies, priorities, resource monitoring and resource managemen t. It is often used as lo cal sc heduler within a virtual organization. In this section, w e briery lo ok at v arious features pro vided b y Condor. Some of the features pro vides b y Condor include F r amework for Opp ortunistic Computing : Opp ortunistic Computing is the utilization of all the a v ailable resource without requiring 100% a v ailabilit y Condor eectiv ely harnesses the a v ailable CPU cycles b y sending jobs to idle w orkstations. It pro vides queuing, sc heduling and planning facilities to ac hiev e this. ClassA ds : ClassAds[ 14 ] pro vide a mec hanisms for matc h-making. Both Buy ers and Sellers of resources publish a classie d advertisement and Condor's Matc hMak er matc hes the requests with a v ailable resources. The Matc hMak er emplo ys a simple matc hing algorithm that follws the constrain ts and p olicies sp ecied in the adv ertisemen ts. A ClassAd example is sho wn in gure 2{2 Che ckp ointing and Migr ation : When users start using idle w orkstations, sometimes it is necessary to mo v e the running jobs to other a v ailable idle w orkstations. This requires c hec kp oin ting and migration facilities. Condor pro vides these features with some constrain ts. When a job needs to b e migrated, Condor creates a snapshot of the job called a c hec kp oin t, whic h includes detailed accoun t of pro cess state. When the job is re-started on another mac hine, the c hec kp oin t le is used to re-create its state. Programs ha v e to b e re-link ed with the Condor c hec kp oin ting libraries to exploit this feature.

PAGE 19

11 [ Type = "Job"; Owner = "ppadala"; Universe = "Standard"; Requirements = (other.OpSys == "Redhat Linux" && other.DiskSpace > 500M); ClusterID = 1234; JobID = 0; Env = "" Groups = {"condor", "griphyn"}; Files = { [ name = "simulation_data.txt", type = "input"], [ name = "analysis.dat", type = "output"] } .... ] Figure 2{2: A ClassAd example

PAGE 20

12 Split Exe cution System : Condor pro vides in terp osition agen ts so that a program executing on a remote system can transparen tly mak e a system call to the originating system. This is useful in running legacy applications unmo died on a remote system. Condor-G: A Computation Management A gent for Grid Computing : CondorG pro vides facilities to com bine Condor and Globus tec hnologies. Condor can b e used b oth as a fron tend and bac k end to Globus to olkit mec hanisms. It pro vides a consisten t in terface to submit jobs to resources managed in dieren t w a ys. 2.6 Legion Legion[ 3 ] is an ob ject-based meta computing system that en visions pro viding a virtual w orld-wide computer view to the user. Using Legion, users see a single computer with enormous resources. Groups of users can construct a virtual w orkspace to collabarate and access resources. Legion sits on top of user's op erating system and using its sc heduling and resource managemen t algorithms pro vides this view. Legion pro vides v arious features including Obje ct-b ase d Meta System : Legion pro vides an ob ject-based meta system in whic h core ob jects lik e host ob jects and v ault(storage) ob jects. The core ob jects pro vide the basic framew ork for building adv anced services. Ev ery thing in Legion is an ob ject and the ob jects are p ersisten t. Users can create new classes that allo ws a p o w erful mec hanism to extend Legion capabilities. L e gion File System : Legion le system is dev elop ed to cop e with the div erse requiremen ts of wide-area collabarations. It pro vides a fully in tegrated arc hitecture that pro vides lo cation indep enden t naming, securit y scalabilit y extensibilit y and adaptabilit y R esour c e Management Servic es : Legion pro vides an ob ject-based resource managemen t system that allo ws user-dened sc hedulers. The resource mo del con tains basic resources (hosts and v aults), the information database (the Collection), the sc heduler implemen tor (the Enactor) and an execution monitor. See [ 15 ] for more details on these comp onen ts. 2.7 Previous W ork The primary motiv ation for this w ork comes from c hapter t w en t y of the b o ok The A natomy of the Grid: Enabling Sc alable Virtual Or ganizations edited b y Ian F oster et al[ 1 ], in whic h the authors discuss the c hallenges in the op erating system

PAGE 21

13 in terfaces for grid arc hitectures. The b o ok discusses v arious principles but stops short of implemen tation details. While there has b een little w ork on Grid Op erating System in terfaces, there has b een tremendous dev elopmen t in grid middlew are. Pro jects lik e Globus and Legion pro vide elab orate soft w are infrastructure for writing grid applications. These to ols and libraries ha v e to cop e with the existing op erating system services that are not designed for high-p erformance computing. As a result, they are forced to implemen t some commonly used high-p erformance optimizations lik e m ultiple TCP streams and TCP buer size negotiation that more suitably should b e implemen ted in the op erating system's k ernel. These to ols, though quite dieren t, often use the same set of lo w-lev el services lik e resource managemen t, pro cess managemen t, and high-p erformance I/O. F or example, b oth Globus and Legion ha v e to query the op erating system for resources and main tain information for eectiv e resource managemen t. As there is no op erating system supp ort for these lo w-lev el services, middlew are dev elop ers m ust implemen t them from scratc h. This is error prone and often results in sub-optimal solutions. There ha v e b een some attempts to add op erating system services that p erform high p erformance computing. W ebOS[ 16 ] pro vides op erating system services for wide area applications pro vides services for wide area applications. PODOS[ 17 ], a p erformance orien ted distributed op erating system, is similar and pro vides high p erformance through optimized services in the k ernel. This w ork succeeds in pro viding high p erformance. But due to the extensiv e c hanges made to the k ernel, it is dicult to p ort this w ork to new er k ernels. It is also dicult to extend the services due to its monolithic structure. GridOS addresses these problems b y pro viding a mo dular arc hitecture that requires minimal c hanges to the k ernel and mak es it easy to extend the services.

PAGE 22

14 Apart from the ab o v e men tioned w ork, there has b een great amoun t of researc h done in distributed op erating systems. Systems lik e Amo eba[ 18 ] and Sprite[ 19 ] had great impact on the distributed programming paradigm. W e ha v e incorp orated some of the principles used in designing these distributed op erating systems in GridOS.

PAGE 23

CHAPTER 3 GRIDOS DESIGN 3.1 Core Principles The follo wing principles driv e the design of GridOS. These principles deriv e from the fact that the to olkits lik e Globus require a common set of services from the underlying op erating system. Mo dularity The k ey principle in GridOS is to pro vide mo dularit y The comp onen ts of GridOS should b e mo dular and in teract with w ell-dened in terfaces. The Lin ux k ernel mo dule arc hitecture is exploited to pro vide a clean mo dular functionalit y Policy Neutr ality GridOS follo ws one of the guiding principles of design of op erating systems: p olicy-free mec hanisms. Instead of pro viding a black b ox implemen tation that tak es care of all p ossibilities, the mo dules pro vide a p olicy-free API that can b e used to dev elop high lev el services lik e GridFTP Higher lev el middlew are, ha ving more information ab out the application should b e able to setup p olicies using GridOS APIs. Universality of Infr astructur e GridOS pro vides a basic set of services that are common to prev alen t grid soft w are infrastructures. It should b e easy to build radically dieren t to olkits lik e Globus (a set of indep enden t services) and Legion (an ob ject-based meta-systems infrastructure). Minimal Cor e Op er ating System Changes W e do not w an t to mak e extensiv e mo dications to the core op erating system as that w ould mak e it dicult to k eep up with new OS v ersions. These guiding principles led us to dev elop a la y ered arc hitecture (Figure 3{1 ). The lo w est la y er con tains the primary GridOS mo dules that pro vide highp erformance grid computing facilities. These mo dules are orthogonal and pro vide basic mec hanisms. They do not mandate an y p olicies. The upp er la y ers pro vide sp ecic services similar to GridFTP GASS[ 20 ]. This approac h is motiv ated b y the observ ation that the to olkits usually mak e p olicy decisions on b ehalf of the grid applications. The to olkit, kno wing the 15

PAGE 24

16 Globus gridos_rm gridos_io Core syscall/ioctl interface Middleware Kernel Grid Applications Legion gridos_ftp_server gridos_comm gridos_ftp_common gridos_ftp_client UNICORE libgridos gridos_pm Figure 3{1: Ma jor mo dules and structure of GridOS application requiremen ts and ha ving domain kno wledge, can mak e a b etter decision ab out what p olicy to emplo y This also encourages a wide v ariet y of to olkits to b e dev elop ed on top of GridOS. The GridOS core services are pro vided b y an ioctl and sytem call in terfaces. A library called libgridos is dev elop ed to pro vide wrapp ers to the lo w-lev el in terfaces. V arious kinds of middlew are can b e dev elop ed on top of the library T o olkit dev elop ers should normally b e able to use the libgridos API for accessing GridOS services. 3.2 Core Mo dules In the follo wing sections w e describ e GridOS mo dules. W e explain the implemen tation details in a later c hapter.

PAGE 25

17 3.2.1 gridos io: High-P erformance I/O Mo dule High p erformance I/O is an imp ortan t asp ect of grid applications. This mo dule pro vides High-P erformance net w ork I/O capabilities for GridOS. In an increasing n um b er of scien tic disciplines, large amoun ts of data (sometimes on the order of p etab ytes) are accessed and analyzed regularly F or transp orting these large amoun ts of data, high-sp eed W ANs are used. These net w orks ha v e high bandwidth and large round trip times (R TT), sometimes referred to as \Long F at Net w orks" (LFNs, pronounced \elefan(t)s") [ 21 ]. In order to tak e full adv an tage of these high sp eed net w orks, v arious op erating system parameters m ust b e tuned and optimized. Sev eral tec hniques for ac hieving high-p erformance are outlined b elo w. It is imp ortan t to realize that some of these tec hniques are not additiv e, but rather complemen tary Applying a single tec hnique ma y ha v e little or no eect, b ecause the absence of an y one of the tec hniques can create a b ottlenec k. No User-Space Cop ying A user-space FTP serv er requires the k ernel to cop y the net w ork buers to user-space buers to retriev e data from the clien t. It then requires the k ernel to cop y the user-space buer to le system buers to write data to a le. This incurs a large o v erhead due to time sp en t in cop ying. Because gridos io and gridos ftp are k ernel mo dules that handle b oth net w ork and le system I/O, th us double cop ying can b e a v oided. TCP W AN Throughput TCP (T ransmissions Con trol Proto col)[ 22 ] is the standard transp ort la y er used o v er IP net w orks. TCP uses the congestion windo w (CWND), to determine ho w man y pac k ets can b e sen t b efore w aiting for an ac kno wledgmen t. On wide area net w orks, if CWND is to o small, long net w ork dela ys will cause decreased throughput. This follo ws directly from Little's La w[ 23 ] that W indow S iz e = B andw idth D el ay

PAGE 26

18 The bandwidth is the bandwidth of the slo w est link in the path. This can b e measured with to ols lik e pipechar and pchar The dela y can b e measured b y calculating the round trip time (R TT) using ping or traceroute The TCP slow start and c ongestion avoidanc e algorithms determine the size of the congestion windo w. The k ernel buers are allo cated dep ending on the maxim um size of the congestion windo w. T o get maximal throughput it is essen tial to use optimal TCP send and receiv e k ernel buer sizes for the W AN link w e are using. If the buers are to o small, the TCP congestion windo w will nev er fully op en up. If the buers are to o large, a fast sender can o v errun a slo w receiv er, and the TCP windo w will sh ut do wn. The optimal buer size for a link is bandwidth RTT [ 24 25 ] Apart from the default send and receiv e buer sizes, maxim um send and receiv e buer sizes m ust b e tuned. The default maxim um buer size for Lin ux is only 64KB whic h is quite lo w for high-sp eed W ANs. The gridos io mo dule pro vides v arious w a ys of con trolling these buer sizes. Using the gridos system call, default v alues for the buers can b e sp ecied. This ma y b e done b y the system administrator who has kno wledge ab out the net w orks. gridos io measures the throughput from time to time and up dates the buer sizes accordingly 3.2.2 gridos comm: Comm unication Mo dule Comm unication is an imp ortan t asp ect of a distributed application. Often applications require v arious mo des of comm unication dep ending on the underlying medium, destination and target application. F or example, an application transferring a h uge le requires the net w ork pip e to b e full and w an ts to utilize all the a v ailable bandwidth. On the other hand, an application using MPI calls to comm unicate with jobs distributed o v er a wide area net w ork, requires a quic k deliv ery of short messages.

PAGE 27

19 The F oster et al. summarizes the requiremen ts for m ultiple metho ds of comm unication in [ 26 ]. Our in terpretation of these requiremen ts in the con text of GridOS is as follo ws. Sep ar ate sp e cic ation of c ommunic ation interfac e and c ommunic ation metho d : V arious comm unication metho ds are used to send and receiv e messages. F or example, TCP/IP net w orks pro vide reliable (TCP) and un-reliable (UDP) comm unication mec hanisms. But, the in terface to these lo w-lev el comm unication primitiv es need to b e consisten t and should b e sep erate from the underlying mec hanisms. Globus and Legion to olkits already ac hiev e this but with considerable dicult y GridOS oers consisten t primitiv es to async hronous, sync hrnous and reliable, unreliable comm unications. A utomatic sele ction : Automatic selection of comm unication heuristics is required for ease of programming. Though this is in the domain of middlew are, GridOS tries to select appropriate comm unication mec hanism using simple heuristics. Note that all the parameters of GridOS can b e man ually selected b y the middlew are la y er as explained b elo w. Manual sele ction : Grid middlew are should allo w the user to man ually select comm unication metho ds. The middlew are requires man ual selection primitiv es from underlying system lik e GridOS. Err or Hand ling & F e e db ack : Metho d sp ecic feedbac k is required in some applications. F or example, a m ultimedia application migh t w an t to kno w ab out the jitter and frame loss rate so that it can optimize the comm unication. GridOS pro vides this information to the middlew are through w ell-dened in terfaces. The comm unication mo dule is designed so that middlew are writers can pro vide m ultiple comm unication metho ds that supp ort b oth automatic and programmerassisted metho d selection. Grid applications are heterogeneous not only in their computational requiremen ts, but also in their t yp es of comm unication. Dieren t comm unication metho ds dier in usage of net w ork in terfaces, lo w-lev el proto cols and data enco dings and ma y ha v e dieren t qualit y of service requiremen ts. This mo dule allo ws comm unication op erations to b e sp ecied indep enden t of metho ds used to implemen t them.

PAGE 28

20 The mo dule also pro vides m ulti-threaded comm unication whic h is used in implemen ting the FTP mo dule. Using the library v arious high-lev el mec hanisms lik e MPI (Message P assing In terface)[ 27 ] can b e easily implemen ted. 3.2.3 gridos rm: Resource Managemen t Mo dule Grid systems allo w applications to assem ble and use collections of resources on an as-needed basis, without regard to ph ysical lo cation. Grid middlew are and other soft w are arc hitecture that manage resources ha v e to lo cate and allo cate resources according to application requiremen ts. They also ha v e to manage other activities lik e authen tication and pro cess creation that are required to prepare a resource to use. See [ 10 ] for details on v arious issues in v olv ed in resource managemen t. In terestingly these soft w are infrastructure use a common set of services. Gridos rm pro vides these facilities so that soft w are infrastructure can b e dev elop ed to address higher-lev el issues lik e co-allo cation, online-con trol etc. The mo dule pro vides facilities to query and use resources. The mo dule main tains information ab out curren t resource usage of pro cesses started b y lo cal op erating system and GridOS mo dules. It also pro vides facilities to reserv e resources. These facilities can b e used to dev elop systems lik e Condor[ 13 ], whic h disco v ers idle resources on a net w ork. 3.2.4 gridos pm: Pro cess Managemen t Mo dule This mo dule allo ws creation and managemen t of pro cesses in GridOS. It pro vides a global PID (GPID) for ev ery pro cess in GridOS and pro vides comm unication primitiv es whic h can b e used on top of gridos comm for pro cesses to comm unicate among themselv es[ 28 ]. This feature allo ws disparate to olkits lik e Condor and Globus to use a common mec hanism for creating pro cesses and pass pro cess ids. The global PID is created b y com bining the host iden tier and lo cal pro cess id. The mo dule also pro vides

PAGE 29

21 services for pro cess accoun ting. This feature is imp ortan t in accoun ting for the jobs whic h are transp orted to GridOS. 3.3 Additional Mo dules 3.3.1 gridos ftp common This mo dule pro vides facilities common to an y FTP clien t and serv er. This includes parsing of FTP commands, handling of FTP resp onses etc. 3.3.2 gridos ftp serv er This mo dule implemen ts a simple FTP serv er in k ernel space. Due to its design, cop ying of buers b et w een user and k ernel space is a v oided. The serv er do es not start a new pro cess for eac h clien t as is usually done in t ypical FTP serv ers. This incurs lo w o v erhead and yields high-p erformance. The serv er also uses gridos io facilities to monitor bandwidth and adjust the le system buer sizes. The le system buers are c hanged dep ending on the le size to get maxim um o v erlap b et w een net w ork and disk I/O. The mo dule is designed with securit y in mind. Ev en while op erating in the k ernel mo de it drops all privileges and switc hes to an unprivileged user-id and group-id. It also c hro ots to FTP top lev el directory docroot whic h can b e congured dynamically. 3.3.3 gridos ftp clien t This mo dule implemen ts a simple FTP clien t in the k ernel. The main purp ose of this mo dule is to decrease the o v erhead of writing or reading le on the clien t side. Our exp erimen ts indicate that primary o v erhead on the clien t side is the time sp en t in reading and writing les. By carefully optimizing the le system buers to ac hiev e maxim um o v erlap b et w een net w ork and disk I/O, high-p erformance is ac hiev ed.

PAGE 30

CHAPTER 4 IMPLEMENT A TION W e ha v e implemen ted a subset of GridOS on Lin ux using the stable 2.4.19 k ernel. The Lin ux k ernel mo dule arc hitecture is exploited to pro vide ease of installation for users and ease of mo dication for dev elop ers. The co de is divided in to a small patc h to the core k ernel and a set of k ernel mo dules. The patc h is designed to b e minimal and adds the basic ioctl and syscall in terfaces to GridOS. The mo dules are inserted and remo v ed using insmod and rmmod utilities. The dep endencies b et w een the mo dules are resolv ed using modules.dep As a result, if gridos comm is inserted without inserting gridos io the k ernel w ould nd that there is a dep endency and insert gridos io automatically Curren tly w e ha v e implemen ted gridos io gridos ftp server gridos ftp client and the library wrapp er libgridos W e ha v e also implemen ted a simple middlew are called gridos-middleware as a pro of-of-concept sho wing the ease with whic h middlew are can b e dev elop ed. The follo wing sections explain the in ternals of the mo dules. 4.1 Lin ux Kernel Mo dule Arc hitecture The Lin ux k ernel mo dule arc hitecture pro vides micro k ernel facilities to a monolithic design. In the olden da ys, to add features to the Lin ux k ernel, one had to mo dify the source and build a new k ernel. This is still true for core parts of the k ernel lik e the sc heduler. Loadable k ernel mo dules are dev elop ed as a w a y of adding non-core features easily in to the k ernel. Once loaded in to memory the k ernel mo dule b ecomes part of the running k ernel. 22

PAGE 31

23 There are man y adv an tages to using loadable k ernel mo dules. Some of the adv an tages are No need to re-build the k ernel. As a result, mo dules can b e added to and remo v ed from a running k ernel without reb o oting the mac hine or compiling a new k ernel. Easy to diagnose problems. If a loaded driv er is causing problems in a p erfectly running k ernel, the problem is probably with the driv er. Can sa v e memory Administrators can unload mo dules that are not used and free up memory Lin ux pro vides automatic mo dule loading and unloading as w ell. Pro vides mo dularit y Dieren t p eople can w ork on v arious mo dules without w orrying ab out making conricting c hanges to the k ernel. 4.2 Kernel Lev el W eb/Ftp Serv er (tux) T ux is an HTTP proto col la y er and a w eb serv er ob ject cac he in tegrated in to the Lin ux Kernel. It can b e though t of as a k ernel-lev el w eb serv er. TUX stands for Threaded linUX h ttp la y er. T ux is an in teresting concept similar to the metho ds used in High-Throughput Computing. It pro vides high-p erformance w eb serv er b y a v oiding cop ying of net w ork buers b et w een user and k ernel mo de. Usually w eb serv ers are big piece of soft w are written in user-mo de. When the data arriv es o v er net w ork, k ernel copies the data in to user-mo de buers from k ernel net w ork buers. When highp erformance is needed, this b ecomes a b ottlenec k and ma y pro duce lot of o v erhead. If the w eb serv er is just serving static con ten t, then this cop ying of data bac k and forth from user to k ernel mo de can b e a v oided b y ha ving a small k ernel w eb serv er. T ux lls this gap p erfectly b y serving static con ten t directly from k ernel mo de and lea ving dynamic con ten t lik e CGI to an external w eb serv er lik e Apac he. This section pro vides a brief o v erview and co de review of T ux. I also indicate v arious parts of tux that are used in implemen ting GridOS mo dules.

PAGE 32

24 4.2.1 User Lev el Access to k ernel HTTP la y er User pro cesses can access the T ux serv er b y using the sys tux system call. Using this system call, user pro cesses (usually the rc scripts) can driv e the serv er. The caller sp ecies v arious actions lik e startup, sh utdo wn serv er, start thread etc. Startup : The startup action sets up TUX data structures dep ending on the parameters passed from user mo de. These include the n um b er of threads, buer sizes, etc. Shutdown : This action sh uts do wn TUX cleaning up the memory used b y TUX. R e gister Mo dule : TUX pro vides mo dule facilities so that a user can write a user-mo de mo dule to handle sp ecic activit y lik e CGI query handling. The register action registers a handler that will b e called based on a sp ecic action. Un-r e gister Mo dule : This action unregisters the mo dule. Start Thr e ads : This is one of the imp ortan t actions of TUX. TUX do es its o wn handling of k ernel threads. As a result, TUX is m uc h faster than other similar soft w are using k ernel threads. Figure 4{1 sho ws relev an t co de. Note that this co de and other co de snipp ets are simplied for clarit y 4.2.2 Listening & Accepting Messages The listener threads in tux listens to an y requests and accepts the connections. The function start listening listens on the sp ecied so c k et and accepts connectionns through accept requests function. The start listening function is used with small mo dications in GridOS to accept incoming connections. Figure 4{2 sho ws relev an t pieces of co de. An ev en t lo op w aits for accepted connections. The ev en t lo op go es through all the threads c hec king for p ending connections requiring pro cessing. Once an accepted connection is found, it remo v es it from the accept queue and pro cesses the con ten t of request. Figure 4{3 sho ws the ev en t lo op. The proto> got request is the function h ttp got request whic h calls parse request. parse request calls parse message whic h will parse the message and nally calls

PAGE 33

25 switch (action) { case TUX_ACTION_STARTUP: lock_kernel();ret = user_req_startup(); unlock_kernel();goto out; case TUX_ACTION_SHUTDOWN: /* code similar to above */ case TUX_ACTION_REGISTER_MODULE: ret = user_register_module(u_info); goto out; case TUX_ACTION_UNREGISTER_MODULE: ret = user_unregister_module(u_info); goto out; case TUX_ACTION_STARTTHREAD: { unsigned int nr; /* get the number of threads */ ret = copy_from_user(&nr, &u_info->thread_nr, sizeof(int)); error_handling;ti = threadinfo + nr; /* stuff added to process structure */ current->tux_info = ti; current->tux_exit = tux_exit; lock_kernel();/* the real thing */ ret = user_req_start_thread(ti); unlock_kernel();/* after returning set tux_info and tux_exit to null */ } } Figure 4{1: T ux actions

PAGE 34

26 struct socket start_listening(tux_socket_t *listen, int nr) { err = sock_create(PF_INET, SOCK_STREAM, IPPROTO_TCP, &sock); if (err < 0) { goto err; }/* Bind the socket: */ sin.sin_family = AF_INET; sin.sin_addr.s_addr = htonl(addr); sin.sin_port = htons(port); sk = sock->sk; sk->reuse = 1; sk->urginline = 1; #define IP(n) ((unsigned char *)&addr)[n] err = sock->ops->bind(sock, (struct sockaddr*)&sin, sizeof(sin)); if (err < 0) { goto err; }/* sk structure contents are filled with appropriate values for performance gain. */ err = sock->ops->listen(sock, tux_max_backlog); if (err) { goto err; }return sock; error_handling; } Figure 4{2: Connection accept

PAGE 35

27 switch (action) { case TUX_ACTION_EVENTLOOP: eventloop: req = ti->userspace_req; if (req) zap_userspace_req(req); ret = event_loop(ti); goto out_userreq; ... }static int event_loop (threadinfo_t *ti) { ..__set_task_state(current, TASK_INTERRUPTIBLE); work_done = 0; if (accept_pending(ti)) work_done = accept_requests(ti); .. } Figure 4{3: Ev en t lo op

PAGE 36

28 /* Puts newly accepted connections into the inputqueue. This is the first step in the life of a TUX request. */ int accept_requests (threadinfo_t *ti) { ...tp1 = &sock->sk->tp_pinfo.af_tcp; /* Quick test to see if there are connections on the queue. This is cheaper than accept() itself because this saves us the allocation of a new socket. (Which doesn't seem to be used anyway) */ if (tp1->accept_queue) { tux_proto_t *proto; /* set task state to running */ new_sock = sock_alloc(); error_handling;new_sock->type = sock->type; new_sock->ops = sock->ops; error = sock->ops->accept(sock, new_sock, O_NONBLOCK); ...proto = req->proto = tux_listen->proto; proto->got_request(req); /* this will call http_got_request */ } } Figure 4{4: Accept request

PAGE 37

29 h ttp parse message. The request functions ha v e b een mo died in GridOS to handle GridOS sp ecic connections. Other co de in GridOS is written from scratc h. 4.3 Mo dules 4.3.1 Activ ation The mo dules activ ation and de-activ ation is done with usual insmo d and rmmo d commands. Apart from the basic mo dule dep endency features pro vided b y the Lin ux k ernel, I dev elop ed a mec hanism to c hec k whether a required GridOS is mo duled is loaded. Eac h GridOS mo dule after startup up dates a global k ernel structure (after taking care of the sync hronization issues). When a GridOS mo dule starts up, it c hec ks whether all core mo dules are presen t or not. Then, it c hec ks for the existence of required additional mo dules. 4.3.2 IO Mo dule The globus IO mo dule implemen tation is divided in to t w o APIs, one eac h for the net w ork and the le system. The IO mo dule is designed to minimize cop y op erations and let the data ro w remain within the k ernel. The net w ork API includes functions to read and write data from a gridos managed so c k et. Both blo c king and non-blo c king read calls are pro vided. Gridos FTP mo dules mak e extensiv e use of non-blo c king reads for high-p erformance. It also has functions to set v arious buer managemen t options. gridos io sync r e ad : This function is used to read data from a gridos managed so c k et in blo c king mo de. gridos io async r e ad : This function is used to read data from a gridos managed so c k et in non-blo c king mo de gridos io write : This function writes data to the gridos managed so c k et gridos io buer setopt : This function sets options for buer managemen t. The options include setting of TCP send and receiv e buer sizes, maxim um TCP buer size etc. gridos io buer getopt : This function returns the curren t buer managemen t options.

PAGE 38

30 int gridos_io_file_write(const char *buf, const char *dst, int size) { struct file *f = NULL; int flags, len; mm_segment_t oldmm; int mode = 0600; flags = O_WRONLY; if(!dst) { printk(KERN_ERR "Destination file name is NULL\n"); return -1; }f = filp_open(dst, flags, mode); if (!f || !f->f_op || !f->f_op->write) { printk(KERN_ERR "File (write) object is NULL \n"); return -1; }f->f_pos = 0; oldmm = get_fs(); set_fs(KERNEL_DS); len = f->f_op->write(f, buf, size, &f->f_pos); set_fs(oldmm);if (f->f_op && f->f_op->flush) { lock_kernel();f->f_op->flush(f);unlock_kernel(); }fput(f);printk(KERN_INFO "Wrote %d bytes\n", len); return len; } Figure 4{5: File write function listing The le system API has similar functions for reading and writing data to les. These functions call the Lin ux Kernel's VFS (Virtual File System) functions to ac hiev e this. Here is some sample co de sho wing implemen tation details (simplied for clarit y) The le system API also has a higher-lev el function gridos file copy whic h can b e used to cop y a le lo cally This can b e used for high-p erformance lo cal cop ying of les.

PAGE 39

31 gridos io also has facilities to compressed gzip data stream. This can b e congured b y setting the compression option. 4.3.3 FTP Clien t and Serv er Mo dules The FTP serv er API allo ws the user to create an FTP serv er on a sp ecied p ort. V arious conguration options lik e docroot (top lev el directory for anon ymous FTP) threads (n um b er of sim ultaneous threads) etc can b e set to con trol the b eha viors of FTP mo dule. Dynamic conguration can b e done via Lin ux's sysctl mec hanism. This pro vides access to FTP mo dule features through /proc in terface whic h can b e used to read and mo dify v arious v ariables in the k ernel address space. Threading Mo del F or high p erformance k ernel threads are used to satisfy sim ultaneous connections. The thread mo del has b een adapted from TUX, a k ernel w eb serv er. The mo del is similar to the FLASH w eb serv er[ 29 ] where requests are handled sim ultaneously while managing an y disk I/O async hronously in separate threads. There are t w o thread p o ols. The rst p o ol of threads is I/O or c ache-miss thread p o ol. These threads p opulate the buers async hronously at the request of listener threads. The n um b er of I/O threads can b e c hanged b y setting the num threads conguration option. All the threads are started at the start of gridos ftp serv er mo dule. The second p o ol of threads is fast or listener threads. These threads handle requests and send resp onses to clien ts. 4.4 Library W rapp er There are three w a ys of con trolling gridos b eha vior from user-space. Through system call sys gridos Using io ctl on gridos device Using /pro c in terface

PAGE 40

32 libgridos pro vides an easy-to-use in terface to these three lo w lev el in terfaces. Curren tly C function wrapp ers are pro vided to Read and write from/to the net w ork Read and write from/to les Set conguration options Start and Stop FTP serv er Use the FTP clien t 4.5 GridOS Middlew are One of our design goals is to ease the dev elopmen t of middlew are lik e Globus. W e ha v e dev elop ed a small middlew are protot yp e, whic h pro vides uniform access to les whether they are lo cated remotely or lo cally The op erations are similar to the op erations pro vided b y Globus GASS. W e dev elop ed this library in just a few da ys and it sho ws ho w easy it is to dev elop middlew are using GridOS. V arious kinds of applications can b e dev elop ed using the middlew are.

PAGE 41

CHAPTER 5 SCENARIOS 5.1 Scenario #1: T ransp orting a le In this section, w e sho w mo dule in teraction while transp orting a le. The le transp orting is initiated b y a user-space application lik e gridos-middleware that uses sys gridos Dep ending on the parameters v arious GridOS mo dules do the required w ork. In this case gridos ftp client calls gridos io file read whic h reads the le in to le system buers. The buers are used directly to initiate the net w ork IO. On the serv er side the net w ork buers are handed o v er to gridos ftp server whic h can initiate a le writing with gridos io file write Figure 5{1 sho ws the scenario in detail. The pro cess of starting the ftp serv er is not sho wn in the gure. In comparison, gurer 5{2 sho ws le transfer using a normal ftp clien t and serv er. In this scenario, y ou can see that double cop ying is done b et w een user-mo de and k ernel-mo de. In the GridOS scenario double cop ying is a v oided b y handling the transfers within the k ernel. 5.2 Scenario #2: Reading and W riting to a le lo cally In this scenario, w e sho w the usage of gridos file copy that can b e used to cop y a le lo cally As there is no cop ying b et w een user and k ernel mo de, the p erformance is impro v ed. Figure 5{3 sho ws the scenario in detail. 33

PAGE 42

34 data control Network Server Client gridos_ftp_client gridos_io 6 2 1 Kernel-Mode UserMode 4 VFS VFS 6 generic_file_write 5 gridos_io_file_write 4 gridos_ftp_listen 3 generic_file_read 2 gridos_io_file_read 1 sys_gridos 3 5 gridos_io gridosmiddleware gridos_ftp_server Figure 5{1: T ransp orting a le using GridOS VFS VFS Client Server 1 2 3 4 5 6 UserMode KernelMode Client Server Network controldata Network Buffer Cache 1 read from file2 write to socket3 generic_file_read4 read from socket 5 write to file6 generic_file_write Network Buffer Cache Figure 5{2: T ransp orting a le using normal FTP clien t and serv er

PAGE 43

35 UserMode KernelMode file system buffer gridos_io data control 1 1 sys_gridos2 generic_file_read3 generic_file_write 2 3 gridosmiddleware Figure 5{3: Reading and writing to a le

PAGE 44

CHAPTER 6 PERF ORMANCE W e ha v e conducted v arious exp erimen ts to measure the p erformance of GridOS comparing it to standard OS services and Globus services. The use of GridOS services results in a dramatic increase in throughput in our exp erimen ts. First, w e compare ftp p erformance using GridOS and the standard proftp d shipp ed with Mandrak e Lin ux, whic h sho w cases the adv an tages of zero-cop y I/O. Then, w e compare p erformance of transp orting a le using GridFTP serv er and GridOS ftp using globus-url-copy as the clien t. This rev eals an imp ortan t b ottlenec k in high-p erformance I/O: le writing o v erhead. Finally w e compare p erformance of le transfer using GridOS ftp clien t and serv er and globus-url-copy and GridFTP serv er. The exp erimen ts conrm that on a v erage GridOS is 4 times faster than ftp and 1.5 times faster than GridFTP 6.1 T est En vironmen t and Metho dology The tests are conducted in an exp erimen tal grid setup in the self-managed net w ork of CISE at UFL. Globus to olkit v ersion 2.2 is used for setting up the grid. The t w o testing mac hines w ere connected o v er 100Mbps Ethernet net w ork. The mac hines w ere k ept idle while running the tests so as not to allo w other pro cesses running on these mac hines aect the p erformance n um b ers. In eac h exp erimen t les of sizes v arying from 1KB to 512MB w ere used and the total time tak en to transp ort eac h of these les w as calculated. F or eac h transfer the a v erage of 5 runs for eac h le w as tak en. T o a v oid the aects of serving from the cac he, the testing mac hine w as reb o oted after eac h run. 36

PAGE 45

37 0 1 2 3 4 5 6 7 8 1 k 4 k 1 6 k 6 4 k 2 5 6 k 1 m 4 m 1 6 m 6 4 m 2 5 6 m F i l e S i z eT h r o u g h p u t i n M B y t e s / s e c G r i d O S P r o f t p d Figure 6{1: GridOS vs Proftp d using standard ftp clien t 0 1 2 3 4 5 6 7 1 k 4 k 1 6 k 6 4 k 2 5 6 k 1 m 4 m 1 6 m 6 4 m 2 5 6 m F i l e s i z eT h r o u g h p u t i n M b y t e s / s e c G r i d O S G r i d F T P Figure 6{2: GridOS ftp vs GridFTP using globus-url-cop y as clien t 6.2 GridOS vs Proftp d In our rst exp erimen t, w e compared the p erformance of the proftp d and GridOS ftp serv ers using the standard ftp clien t shipp ed with Mandrak e Lin ux as the clien t. Results are sho wn in gure 6{1 This exp erimen t sho w-cases the adv an tages of serving the les from within the k ernel. GridOS consisten tly p erforms b etter than Proftp d for all le sizes.

PAGE 46

38 0 2 4 6 8 1 0 1 k 4 k 1 6 k 6 4 k 2 5 6 k 1 m 4 m 1 6 m 6 4 m 2 5 6 m F i l e s i z eT h r o u g h p u t i n M b y t e s / s e c G r i d O S s e r v e r / c l i e n t G r i d F T P s e r v e r / g l o b u s u r l c o p y Figure 6{3: GridOS ftp serv er/clien t vs GridFTP serv er/globus-url-cop y 6.3 GridFTP vs GridOS ftp serv er using globus-url-cop y clien t This exp erimen t w as done using the globus-url-copy clien t for a fair comparison. Results are sho wn in gure 6{2 GridFTP p erforms p o orly for small les due to the o v erhead incurred in the p erforming securit y mec hanisms. GridOS ftp emplo ys the standard ftp passw ord authen tication for securit y W e also conducted exp erimen ts using the standard ftp clien t instead of globusurl-cop y for GridOS. P erformance w as p o or compared to the p erformance obtained using globus-url-cop y Globus-url-cop y is sp ecically designed for high-p erformance computing and has b etter buer managemen t. This led us to dev elop an in-k ernel ftp clien t. 6.4 GridFTP serv er/clien t vs GridOS ftp serv er/clien t In this exp erimen t, globus-url-copy and gridos-ftp-client are used as clien ts for GridFTP and GridOS ftp serv er resp ectiv ely GridOS ftp clien t mak es eectiv e buer managemen t and is designed on the same lines as globus-url-cop y Results are sho wn in gure 6{3 Based on our exp erimen ts w e observ e that the p erformance drop for larger les is due to the o v erhead in v olv ed in disk writes.

PAGE 47

CHAPTER 7 GRID FILE SYSTEM In the later da ys of m y thesis w ork, I started w orking on dev elopmen t of a grid le system. The initial idea w as to dev elop le system primitiv es in the op erating system to pro vide facilities for higher lev el middlew are. But, as it turned out, the le system primitiv es righ tly b elong to the middlew are. In this c hapter, motiv ation for the w ork, design and preliminary implemen tation results are pro vided. In scien tic discplines using a grid, there is a gro wing need to access the data in the traditional le system seman tics. T o pro vide sharing of data generated from heterogeneous le systems in the grid en vironmen t, a logical hierarc hical namespace with asso ciated metadata that allo ws POSIX op erations is required. Curren tly data middlew are that are usually part of the general purp ose grid middlew are lik e Globus[ 2 ] and Legion[ 3 ] pro vide services for data managemen t. In their earlier v ersions, middlew are pro vided incompatible metho ds to access, manipulate and store the data. The Op en Grid Services Arc hitecture(OGSA)[ 7 ] denes the standard comm unication proto cols and formats for building truly in terop erable grid systems. The Op en Grid Services Infrastructure(OGSI)[ 8 ] pro vides the sp ecication for building v arious grid services en visioned in OGSA. These sp ecications ha v e standardized grid services describing ho w they op erate and in teract. OGSI pro vides detailed WSDL sp ecications for standard in terfaces that dene a grid service. The third v ersion of Globus to olkit (GT3) pro vides implemen tation of OGSI sp ecication and pro vides v arious OGSI-complian t basic services including managed job service, index service and reliable le transfer service (RFT). GT3 also pro vides 39

PAGE 48

40 u s e r = p p a d a l a u s e r = s a n j a y g r o u p = u s c m s g r o u p = u f l o r i d a p e r m s = r w x r w x p e r m s = r w x r w x d e s c = ” t e m p o r a r y s p a c e ” r o o t t m p h o m e Figure 7{1: ur.edu logical structure u s e r = p p a d a l a u s e r = s a n j a y g r o u p = u s c m s g r o u p = u f l o r i d a p e r m s = r w x p e r m s = r w x x x d e s c = t e m p o r a r y s p a c e r o o t v d t t m p g l o b u s c o n d o r Figure 7{2: ucsd.edu logical structure higher lev el data services including RLS (Replica Lo cation Service). The data managemen t services RFT and RLS pro vide the basic mec hanisms for data managemen t. A grid application with complex requiremen ts for data managemen t often requires m uc h more than what is pro vided b y the basic services. Some of the features required include le or ob ject lev el lo c king, automatic replica managemen t and logical hierarc hical name space. W e dev elop ed a le system service(FSS) for grids that pro vides a logical heirarc hical name space that allo ws POSIX op erations. 7.1 Motiv ating Example Scien tic applications in domains lik e High Energy Ph ysics, Bioinformatics, Medical Image Pro cessing and Earth Observ ations often analyze and pro duce massiv e amoun ts of data (sometimes of the order of p etab ytes). The applications access and manipulate data stored in v arious sites on the grid. They also ha v e

PAGE 49

41 to distribute and publish the deriv ed data. Let's see a scenario of ho w a t ypical scien tic application in teracts with the data grid. 1. A ph ysicist participating in a high-energy ph ysics exp erimen t w ould lik e to execute a high energy ph ysics application. 2. The application requires v arious input les. It has to nd the lo cation of les using a catalog, index or database system where information ab out lo cation of the le is stored. The application usually uses a logical le name(LFN) to index in to the catalog and nd the ph ysical lo cation. 3. The les ma y ha v e to b e replicated at v arious places in the grid for the application to nd a nearb y lo cation to quic kly access the le. The application ma y also ha v e to prefetc h the le to a designated site for execution of a job that requires the le at that site. 4. The jobs execute using the input les and pro duce deriv ed data. 5. The deriv ed data needs to b e sen t to v arious sites on the grid for usage b y other scien tists and for arc hiv al purp oses. 6. Finally the output data lo cation has to b e published in the catalog. Using curren t middlew are the ab o v e scenario requires the application to p erform complex in teractions with grid services. Also the application cannot p erform the usual POSIX op erations on a logical name. The application do esn't ha v e full details of the le system and op erations lik e nd al l the sites with minimum 100MB temp or ary sp ac e cannot b e p erformed directly Grid File System Service (FSS) pro vides services that allo w an application to b e written in familiar POSIX seman tics. Under the ho o d, FSS p erforms the ab o v e op erations and can optimize the le access. Eac h site participating in the grid exp orts a lo cal le system structure to the w orld. This structure is a logical hierarc h y as dened b y the site administrator. The logical hierarc h y can b e mapp ed to ph ysical resources in v arious w a ys. This

PAGE 50

42 u s e r = p p a d a l a g r o u p = u s c m s p e r m s = r w x r w x d e s c = t e m p o r a r y s p a c e r o o t u f l e d u u c s d e d u t m p v d t g l o b u s c o n d o r Figure 7{3: Find query result logical to ph ysical mapping is main tained in the lo cal LR C (Lo cal Replica Catalog). Figure 7{1 and 7{2 sho w logical mapping for t w o sites ur.edu and ucsd.edu. Note that the logical directories do not ha v e to follo w the ph ysical structure. F or example, /tmp directory on ur.edu ma y b e mapp ed to /cise/tmp where as on ucsd.edu it migh t b e mapp ed to /exp ort/tmp. An application or user can create an applicationor user-sp ecic view of this global structure b y using FSS services. The follo wing scenario claries the usage. 1. A ph ysicist participating in a high-energy ph ysics exp erimen t w ould lik e to execute a high energy ph ysics application 2. The application requests FSS to pro vide an application sp ecic view on the global le system. F or example, an application requests FSS to pro vide all the directories o wned b y user ppadala. This is similar to a find -type d -user ppadala -name "*" command in traditional UNIX le systems. 3. FSS returns a logical hierarc h y sho wn in gure 7{3 4. No w, the application mak es a query on the logical hierarc h y to nd the directory with description \temp orary space" whic h returns /ur.edu/tmp. 5. Application creates les in the temp orary space using the logical name pro vided b y FSS. Under the ho o d, the le is created in the sp ecic site. 6. It closes the le and other applications can see the le.

PAGE 51

43 7. Similarly an existing le can b e found b y p erforming a query F or example, the user migh t b e in terested in all the temp orary les created in v arious sites so that he can delete them. Before w e delv e in to the design of FSS, let us in v estigate the requiremen ts of a grid le system. I am leading a surv ey for grid le system requiremen ts for the GFS-W G (Grid File Systems W orking Group) to understand v arious asp ects of grid le systems. Here w e delv e in to some asp ects of the requiremen ts of a grid le system. 7.2 Requiremen ts In v estigating curren t middlew are used in the data grids and the requiremen ts for data managemen t in v arious grid applications, w e iden tied the follo wing requiremen ts. L o gic al Hier ar chic al Name Sp ac e : Since data is stored in dieren t name spaces in the grid, it is essen tial to ha v e a univ ersal name space encompassing underlying naming mec hanisms. In a data grid, data migh t b e stored in a le, collection of les or in a database table. They ma y b e replicated in v arious sites for eciency A logical hierarc hical name space separates the application from the existing ph ysical le system and pro vides a familiar tree le system structure. Replicas and Soft links complicate the structure. Uniform Stor age Interfac e : The le system should pro vide a transparen t, uniform in terface to heterogeneous storage. Data A c c ess/T r ansfer : Robust and rexible mec hanisms for data access and transfer are required. R eplic a Management : Replication is the pro cess of main taining iden tical copies of data at v arious sites. The main purp ose of replication is to main tain copies of the data at nearb y sites th us increasing read p erformance. But, it in tro duces other issues lik e consistency managemen t and life cycle managemen t. The le system should pro vide basic replica managemen t facilities lik e creation, up date and deletion of replicas. L atency Management : Usually data for a grid application are distributed o v er v arious sites on the grid. A grid le system should pro vide mec hanisms for managing the latency using mec hanisms lik e streaming, disk cac hing, pre-fetc hing and bulk loading. Metadata Management : Metadata is the data ab out the data. There are v arious kinds of metadata describ ed in detail later. A le system should

PAGE 52

44 pro vide basic metadata managemen t facilities and supp ort for at least le lev el metadata. It should also supp ort mec hanisms through whic h additional metadata can b e managed. Optimization and Performanc e : The le system should optimize the data access/transfer using v arious metho ds including data transfer prediction based on past information. Automatic replica managemen t based on application access patterns is required. 7.3 Design In the follo wing sections, w e detail the design of the FSS. 7.3.1 Logical Hierarc hical Name Space The logical hierarc hical name space is the most imp ortan t prop ert y of FSS. Eac h virtual organization or site running FSS can exp ort a logical hierarc h y to the w orld. The site administrator can decide on an y arbitrary logical to ph ysical mapping dep ending on his storage structure. The logical hierarc h y is represen ted as a tree with no des ha ving attributes. The no des ha v e metadata asso ciated with them. The metadata pro vides data ab out le size, creation time, access con trol information etc. More details are in section 7.3.4 An application or user can send a query to lo cal FSS and get a logical view as a result. This approac h is similar to the query-based logical hierarc h y prop osed in the logic le system[ 30 ]. 7.3.2 Data Access/T ransfer and Replica Managemen t FSS builds on top of existing grid services multirft lestr e aming and RLS Figure 7{4 sho ws this la y ered arc hitecture. The m ultirft and lestreaming grid services are used for data access and transfer. FSS uses RLS for basic replica managemen t pro viding more complext features lik e automatic replica managemen t on top of it. 7.3.3 POSIX seman tics FSS pro vides a POSIX seman tics for accessing the les. It pro vides the familiar op en, read, write, close op erations. An application m ust rst request a

PAGE 53

45 F S S R L S G T 3 b a s e s e r v i c e s ( F i l e S t r e a m i n g M u l t i R F T ) G T 3 C o r e G T 3 Figure 7{4: FSS arc hitecture logical view from the lo cal FSS b efore it can do these op erations. The logical view is cac hed b y the lo cal FSS with mappings to ph ysical lo cations for fast access. Details ab out the op erations are giv en b elo w. op en : Op en tak es the le to op en and the rags sp ecifying whether the le should b e op ened as read-only write-only app end or read-write. When a le is op ened for writing, a write lo c k is placed on the le un til the le is closed b y the application. Op en returns a unique handle that can b e used to p erform other op erations. Note that the handle is unique only to the lo cal FSS.The op en request is propagated to the corresp onding site FSS and the metadata corresp onding to the particular le is up dated. FSS creates a lo cal disk cac he for the le. r e ad : The read op eration can b e done on an op en handle. The lestreaming service is used to p erform reads at a particular blo c k. Reads are rst p erformed on the lo cal disk cac he and if the data is not a v ailable in the cac he, it is fetc hed from the remote site. write : W rite op erations write data to an op en le. The writes are rst done to the lo cal cac he and are propagated to the remote site via a bac kground pro cess. The lestreaming service is used to propagate writes. All replicas of the les are also up dated. close : The close op eration p erforms all p ending writes, cleans the disk cac he and up dates the le metadata.

PAGE 54

46 Directory op erations lik e mkdir, op endir, readdir, closedir are pro vided for manipulating directories. 7.3.4 Metadata There are man y kinds of metadata including le lev el metadata, storage metadata, access con trol metadata, application sp ecic metadata etc. FSS attac hes metadata with eac h no de in the logical hierarc hical name space. W e dened the follo wing metadata to b e asso ciated with eac h no de in the logical tree. File L evel Meta Data : This metadata describ es the information ab out the le. This includes size of the le, creation, mo dication and access time, creator and lo c king information. A c c ess Contr ol Meta Data : This describ es the p ermissions on the le. Curren tly FSS supp orts traditional user, group, other p ermissions. Applic ation Sp e cic Meta Data : Scien tic applications often asso ciate v arious metadata including pro v enance and deriv ation information with the les. The desc(description) attribute sho wn in the previous examples is used to pro vide information ab out the directory There is a lot of p oten tial for asso ciating sp ecial purp ose, application sp ecic metadata that can impro v e the queries. 7.3.5 Automatic Data Managemen t FSS can p erform automatic data managemen t dep ending on the le access patterns. F or example, replicating a m uc h accessed le (called hot-sp ot) at v arious sites impro v es p erformance and can b e replicated automatically 7.3.6 P erformance Optimization FSS op ens up lots of p ossibilities for ecien t data managemen t. The logical views for an application group can b e main tained together and can b e cac hed at the lo cal FSS. It can also b e statically stored at a cen tral lo cation lik e metadata catalog serv er.

PAGE 55

47 Aggregation of les as a single le and Distribution of fragmen ts of le pro vide mec hanisms for ecien t distribution of large data. Queries for nding the data can b e optimized and executed b y adding additional attributes to the logical hierarc h y 7.4 Building the Service In this section, w e describ e our preliminary FSS design. Note that these descriptions are only preliminary and will b e impro v ed o v er time. Curren tly w e ha v e dened description for basic op en, read, write, close and getLogicalView op erations. The GWSDL description is sho wn in app endix 9 7.4.1 ServiceData The servicedata will con tain elemen ts for sp ecifying the n um b er of managed les, n um b er of op en les and their status. number of managed files by the service

PAGE 56

48 Status of the file
7.4.2 Notication Man y in teresting scenarios can b e implemen ted using the notications pro vided b y FSS. Notication for c hange of les, c hange of le metadata can b e pro vided. 7.5 Op en Questions There are man y op en questions to b e answ ered for building the le system service. Belo w, W e list a questions w e are exploring. Ho w can w e share the logical views of an application among v arious FSS? What proto col should b e used for this federation? What is the format for logical views that are returned to the application? W e are thinking of returning the view in a XML format. Ho w should one return a partial view if the results are to o big? Ho w can w e ecien tly manage the metadata? W e are thinking of using the meta data catalog serv er that is a v ailable at eac h site for storing metadata of the les related to that site. Ho w should w e propagate the up dates/writes to les and metadata. This is a big researc h question in v olving latency managemen t and consistency proto cols. What are the approac hes for automatic replica managemen t? W e are in v estigating user-initiated, application-initiated, sc heduler-initiated and automatic replica managemen t.

PAGE 57

CHAPTER 8 FUTURE W ORK The w ork presen ted in this thesis is a rst step to w ards a grid op erating system that pro vides extensiv e, rexible services for grid arc hitectures. Our next step is to implemen t all GridOS mo dules. W e ha v e plans to deplo y GridOS in a wide area computing testb ed. It can b e used in nation wide test b eds similar to GriPh yN (Grid Ph ysics Net w ork)[ 31 ] at the Univ ersit y of Florida. Suc h en vironmen ts will enable use to ev aluate GridOS mo dules more realistically There are man y p ossibilities for high lev el middlew are to exploit GridOS functionalit y Globus core libraries can b e p orted to use GridOS functionalit y making them ev en more p o w erful. In teresting scenarios lik e in terop erating b et w een Condor and Globus job IDs using GridOS pro cess managemen t mo dule are w orth exploring. The Grid File System op ens up tremendous opp ortunities for ecien t data managemen t. Ecien t data managemen t tec hniques lik e optimal replica selection mec hanisms can b e dev elop ed using the Grid File System. 49

PAGE 58

CHAPTER 9 CONCLUSIONS W e ha v e describ ed a set of op erating system services for grid arc hitectures. These services mak e a commo dit y op erating system lik e Lin ux highly suitable for high-p erformance computing. W e ha v e iden tied a common set of services that use grid soft w are infrastructures lik e Globus, Legion, Condor etc. The services are dev elop ed as a set of mo dules for ease of use and installation. Our p erformance exp erimen ts sho w that high-p erformance can b e ac hiev ed with GridOS mo dules. W e ha v e also describ ed pro of-of-concept middlew are that uses GridOS facilities. W e presen ted the design for a grid le system that pro vides logical hierarc hical name space, uniform storage in terface, replica managemen t and metadata managemen t. 50

PAGE 59

APPENDIX GRID FILE SYSTEM GWSDL DESCRIPTION 51

PAGE 60

52


PAGE 61

53


PAGE 62

54


PAGE 63

55


PAGE 64

56


PAGE 65

REFERENCES [1] I. F oster and C. Kesselman, editors. The Grid: Blueprint for a F utur e Computing Infr astructur e Morgan Kaufmann Publishers, San F rancisco, California, 1999. [2] I. F oster and C. Kesselman. Globus: A metacomputing infrastructure to olkit. The International Journal of Sup er c omputer Applic ations and High Performanc e Computing 11(2):115{128, 1997. [3] Andrew S. Grimsha w, William A. W ulf, and the Legion team. The legion vision of a w orldwide virtual computer. Communic ations of the A CM 40(1):39{45, Jan uary 1997. [4] V. Hub er. UNICORE: A Grid computing en vironmen t for distributed and parallel computing. L e ctur e Notes in Computer Scienc e 2127:258{266, 2001. [5] Ian F oster. What is the grid? A three p oin t c hec klist. Grid T o day 1(6), July 2002. [6] A. Cherv enak, I. F oster, C. Kesselman, C. Salisbury and S. T uec k e. The data grid: T o w ards an arc hitecture for the distributed managemen t and analysis of large scien tic datasets. Journal of Network and Computer Applic ations 23:187{200, 2001. [7] I. F oster, C. Kesselman, J. Nic k, and S. T uec k e. The ph ysiology of the grid: An op en grid services arc hitecture for distributed systems in tegration. Op en Grid Servic e Infr astructur e WG, Glob al Grid F orum June 2002. [8] S. T uec k e, K. Cza jk o wski, I. F oster, J. F rey S. Graham, C. Kesselman, T. Maguire, T. Sandholm, P V anderbilt, and D. Snelling. Op en grid services infrastructure (ogsi) v ersion 1.0. Glob al Grid F orum Dr aft R e c ommendation July 2003. [9] I. F oster, C. Kesselman, G. Tsudik, and S. T uec k e. A securit y arc hitecture for computational grids. In A CM Confer enc e on Computers and Se curity pages 83{91. A CM Press, 1998. [10] K. Cza jk o wski, I. F oster, N. Karonis, C. Kesselman, S. Martin, W. Smith, and S. T uec k e. A resource managemen t arc hitecture for metacomputing systems. In The 4th Workshop on Job Sche duling Str ate gies for Par al lel Pr o c essing pages 62{82. Springer-V erlag LNCS 1459, 1998. 57

PAGE 66

58 [11] K. Cza jk o wski, S. Fitzgerald, I. F oster, and C. Kesselman. Grid information services for distributed resource sharing. In Pr o c e e dings of the 10 th Symp osium on High Performanc e Distribute d Computing pages 181{195, 2001. [12] Bill Allco c k, Jo e Bester, John Bresnahan, Ann L. Cherv enak, Ian F oster, Carl Kesselman, Sam Meder, V eronik a Nefedo v a, Darcy Quesnel, and Stev en T uec k e. Data managemen t and transfer in high-p erformance computational grid en vironmen ts. Par al lel Computing 28(5):749{771, Ma y 2002. [13] M. J. Litzk o w, M. Livn y and M. W. Mutk a. Condor : A h un ter of idle w orkstations. In 8th International Confer enc e on Distribute d Computing Systems pages 104{111, W ashington, D.C., USA, June 1988. IEEE Computer So ciet y Press. [14] Ra jesh Raman, Miron Livn y and Marvin Solomon. Resource managemen t through m ultilateral matc hmaking. In Pr o c e e dings of the Ninth IEEE Symp osium on High Performanc e Distribute d Computing (HPDC9) pages 290{291, Pittsburgh, P A, August 2000. [15] Stev e J. Chapin, Dimitrios Katramatos, John Karp o vic h, and Andrew S. Grimsha w. Resource managemen t in legion. T ec hnical Rep ort CS-98-09, Departmen t of Computer Science, Univ ersit y of Virginia, F ebruary 11 1998. [16] Amin V ahdat, T om Anderson, Mik e Dahlin, Esh w ar Belani, Da vid Culler, P aul Eastham, and Chad Y oshik a w a. W ebOS: Op erating system services for wide area applications. In Pr o c e e dings of the Seventh Symp osium on High Performanc e Distribute d Computing pages 52{64, July 1998. [17] Sudharshan V azhkudai, Jeelani Sy ed, and T obin Maginnis. PODOS | the design and implemen tation of a p erformance orien ted Lin ux cluster. F utur e Gener ation Computer Systems 18(3):335{352, Jan uary 2002. [18] Andrew S. T anen baum and Sap e Mullender. An o v erview of the Amo eba distributed op erating system. Op er ating Systems R eview 15(3):51{64, July 1981. [19] John K. Ousterhout, A. R. Cherenson, F red Douglis, Mic hael N. Nelson, and Bren t B. W elc h. The Sprite net w ork op erating system. Computer 21(2):23{36, F ebruary 1988. [20] Joseph Bester, Ian F oster, Carl Kesselman, Jean T edesco, and Stev en T uec k e. GASS: A data mo v emen t and access service for wide area computing systems. In Pr o c e e dings of the 6th Workshop on I/O in Par al lel and Distribute d Systems (IOP ADS-99) pages 78{88, New Y ork, Ma y 5 1999. A CM Press. [21] W. R. Stev ens. TCP/IP Il lustr ate d, V olume 1; The Pr oto c ols Addison W esley Boston, Massac h usetts, 1995.

PAGE 67

59 [22] J. P ostel. RF C 793: T ransmission con trol proto col, Septem b er 1981. [23] L. Kleinro c k. Queueing Systems: The ory v olume 1. John Wiley and Sons, New Y ork, 1975. [24] J. Semk e, M. Mathis, and J. Mahda vi. Automatic TCP buer tuning. SIGCOMM 98 pages 315{323, 1998. [25] Brian L. Tierney Jason Lee, Brian Cro wley Mason Holding, Jerem y Hylton, and F red L. Drak e, Jr. A net w ork-a w are distributed storage cac he for datain tensiv e en vironmen ts. In Pr o c e e dings of the Eighth IEEE International Symp osium on High Performanc e Distribute d Computing pages 185{193, Redondo Beac h, CA, August 1999. IEEE Computer So ciet y Press. [26] I. F oster, J. Geisler, C. Kesselman, and S. T uec k e. Managing m ultiple comm unication metho ds in high-p erformance net w ork ed computing systems. Journal of Par al lel and Distribute d Computing 40:35{48, 1997. [27] Message P assing In terface F orum. MPI: A message-passing in terface standard. T ec hnical Rep ort UT-CS-94-230, 1994. [28] P T obin Maginnis. Design considerations for the transformation of MINIX in to a distributed op erating system. In A CM, editor, Pr o c e e dings, fo cus on softwar e / 1988 A CM Sixte enth A nnual Computer Scienc e Confer enc e, F ebruary 23{25, the Westin, Pe achtr e e Plaza, A tlanta, Ge or gia pages 608{615, New Y ork, NY 10036, USA, 1988. A CM Press. [29] Viv ek S. P ai, P eter Drusc hel, and Willy Zw aenep o el. Flash: An ecien t and p ortable w eb serv er. In Pr o c e e dings of the 1999 USENIX A nnual T e chnic al Confer enc e (USENIX-99) pages 199{212, Berk eley CA, June 6{11 1999. USENIX Asso ciation. [30] Y oann P adioleau and Olivier Ridoux. A logic le system. In Pr o c c e dings of USENIX 2003 A nnual T e chnic al Confer enc e pages 99{112. USENIX, June 2003. [31] P aul Av ery and Ian F oster. The griph yn pro ject: T o w ards p etascale virtualdata grids. T ec hnical Rep ort GriPh yN-2000-1, Univ ersit y of Florida, 2001.

PAGE 68

BIOGRAPHICAL SKETCH Pradeep P adala w as b orn on August 22 nd 1979, in Srik akulam, Andhra Pradesh, India. He receiv ed his undergraduate degree, Bac helor of Engineering, computer science and engineering, from Motilal Nehru Regional Engineering College, Allahabad, India, in Ma y 2000. Pradeep w ork ed in Hughes Soft w are Systems from August 2000 to August 2001. He joined the Univ ersit y of Florida in F all 2001 to pursue his master's degree. His researc h in terests include distributed systems and op erating systems with an emphasis on grid computing. More details ab out him can b e found on his w eb site at http://www.cise.ufl.edu/~ppadala 60


Permanent Link: http://ufdc.ufl.edu/UFE0002826/00001

Material Information

Title: Design and Implementation of GridOS: Operating System Services for Grid Architectures
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0002826:00001

Permanent Link: http://ufdc.ufl.edu/UFE0002826/00001

Material Information

Title: Design and Implementation of GridOS: Operating System Services for Grid Architectures
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0002826:00001


This item has the following downloads:


Full Text











DESIGN AND IMPLEMENTATION OF GRIDOS: OPERATING SYSTEM
SERVICES FOR GRID ARCHITECTURES
















By

PRADEEP PADALA


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003


































Copyright 2003

by

Pradeep Padala
















ACKNOWLEDGMENTS

I would like to gratefully acknowledge the great supervision of Dr. Joseph

Wilson during this work. I thank Dr. Michael Frank and Dr. Paul Avery for

serving on my committee and for reviewing my work.

I also would like to thank Dr. Richard Cavannaugh and Dr. Sanjay Ranka for

their helpful 1ii- i..n-, in grid file system work.

I am grateful to all my friends who helped directly or indirectly in preparing

this work.

Finally, I am forever indebted to my parents for helping me to reach this stage

in my life.
















TABLE OF CONTENTS
page

ACKNOWLEDGMENTS ................... .......... iii

LIST OF FIGURES ................... ............. vi

ABSTRACT ........................... .............. vii

1 INTRODUCTION .................. ... 1

2 MOTIVATION .................... ............ 3

2.1 The Grid .................. ............ 3
2.2 Grid Applications ................... ....... 4
2.3 Grid Middleware ................... ....... 5
2.4 Globus .................... ............ 6
2.4.1 Security ............... ........ 8
2.4.2 Data Management .... ........... .... 8
2.4.3 Resource Management ... ............ 9
2.4.4 Information Services ..... ...... ...... .. 9
2.5 Condor ...... .......... ............. 10
2.6 Legion ...... ... .................. 12
2.7 Previous Work . . . ... ......... 12

3 GRIDOS DESIGN . . . . . . . 15

3.1 Core Principles . . . . .. ........ 15
3.2 Core Modules . ............. ......... 16
3.2.1 gridosio: High-Performance I/O Module . .... 17
3.2.2 gridoscomm: Communication Module . . .... 18
3.2.3 gridos-rm: Resource Management Module . .... 20
3.2.4 gridos_pm: Process Management Module . .... 20
3.3 Additional Modules . . . . . . 21
3.3.1 gridos_ftp_common . . . . ... . 21
3.3.2 gridos_ftp_server . . . . . . 21
3.3.3 gridos_ftp_client . . . . . 21

4 IMPLEMENTATION . . . . . . . 22

4.1 Linux Kernel Module Architecture. . . . ... 22
4.2 Kernel Level Web/Ftp Server (tux) . . . ...... 23
4.2.1 User Level Access to kernel HTTP layer . .... 24
iv










4.2.2 Listening & Accepting Messages
4.3 M odules . . . . .
4.3.1 Activation . . .
4.3.2 10 M odule . . .
4.3.3 FTP Client and Server Modules
4.4 Library Wrapper . . .
4.5 GridOS Middleware . . .

5 SCENARIOS . . . . .

5.1 Scenario #1: Transporting a file .
5.2 Scenario #2: Reading and Writing to a


file locally...........


6 PERFORMANCE . . . . . . . .


6.1 Test Environment and Methodology . . .
6.2 GridOS vs Proftpd . . . . .
6.3 GridFTP vs GridOS ftp server using globus-url-copy
6.4 GridFTP server/client vs GridOS ftp server/client .

7 GRID FILE SYSTEM . . . . . .


7.1 Motivating Example . . .
7.2 Requirements . . . .
7.3 D esign . . . . .
7.3.1 Logical Hierarchical Name Space .
7.3.2 Data Access/Transfer and Replica
7.3.3 POSIX semantics . . .
7.3.4 Metadata . . . .
7.3.5 Automatic Data Management
7.3.6 Performance Optimization .
7.4 Building the Service . . .
7.4.1 ServiceData . . .
7.4.2 Notification . . .
7.5 Open Questions . . . .


Management


8 FUTURE WORK . . . . ... . . .

9 CONCLUSIONS . . . . . . . .

APPENDIX Grid File System GWSDL Description . . . .

REFERENCES . . . . ... . . . .

BIOGRAPHICAL SKETCH . . . . . . .


client
















LIST OF FIGURES
Figure page

2-1 Layered grid architecture. . . . . . 7

2-2 A ClassAd example . . . .. ........ 11

3-1 M1. I i modules and structure of GridOS . . . .... 16

4-1 Tux actions . . . . .. ........... 25

4-2 Connection accept . . . . .. ......... 26

4-3 Event loop . . . ... ............ 27

4-4 Accept request . . . . . . . 28

4-5 File write function listing . . . . ... . 30

5-1 Transporting a file using GridOS . . . . ... 34

5-2 Transporting a file using normal FTP client and server . . 34

5-3 Reading and writing to a file . . . . . 35

6-1 GridOS vs Proftpd using standard ftp client . . . 37

6-2 GridOS ftp vs GridFTP using globus-url-copy as client . . 37

6-3 GridOS ftp server/client vs GridFTP server/globus-url-copy . 38

7-1 ufl.edu logical structure ... . . ... ..... 40

7-2 ucsd.edu logical structure ... . . ... .... 40

7-3 Find query result . . . . . . . 42

7-4 FSS architecture . . . . . . .... 45















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

DESIGN AND IMPLEMENTATION OF GRIDOS: OPERATING SYSTEM
SERVICES FOR GRID ARCHITECTURES

By

Pradeep Padala

December 2003

Chair: Joseph N. Wilson
lM. ]Pr Department: Computer and Information Science and Engineering

In this work, we demonstrate the power of providing a common set of op-

erating system services to grid architectures, including high-performance I/O,

communication, resource management and process management. A grid enables the

-. Ii i i selection, and ... .- :regation of a wide variety of geographically distributed

resources including supercomputers, storage systems, data sources, and specialized

devices owned by different organizations administered with different policies. In the

last few years, a number of exciting projects like Globus, Legion, and UNICORE

developed the software infrastructure needed for grid computing. However, oper-

ating system support for grid computing is minimal or non-existent. Tool writers

are forced to re-invent the wheel by implementing from scratch. This is error prone

and often results in sub-optimal solutions. We have developed GridOS, a set of

operating system services that faciliate grid computing. These services, developed

as kernel modules make a normal commodity operating system like Linux highly

suitable for grid computing. The modules are designed to be policy neutral, exploit

commonality in various grid infrastructures and provide high-performance. Our










experiments with GridOS verify that there is dramatic improvement in performance

when compared to the existing grid file transfer protocols like GridFTP. We have

also developed a proof-of-concept middleware using GridOS.















CHAPTER 1
INTRODUCTION

A grid[l] enables the -ih.uiiii-_. selection, and .'. regation of a wide variety of

geographically distributed resources including supercomputers, storage systems,

data sources and specialized devices owned by different organizations administered

with different policies. Grids are typically used for solving large-scale resource

and computing intensive problems in science, (n ii.l.. .iir.. and commerce. In

the last few years, a number of exciting projects like Globus[2], Legion[3] and

UNICORE[4], developed the software infrastructure needed for grid computing.

Various distributed computing problems have been solved using these tools and

libraries. However, operating system support for grid computing is minimal or

non-existent. Though these tools have been developed with different goals, they

use a common set of services provided by the existing operating system to achieve

different abstractions.

GridOS provides operating system services that support grid computing.

It makes writing middleware easier and provides services that make a normal

commodity operating system like Linux more suitable for grid computing. The

services are designed as a set of kernel modules that can be inserted and removed

with ease. The modules provide mechanisms for high performance I/O (gridosio),

communication (gridoscomm), resource management (gridosrm), and process

management (gridos_pm). These modules are designed to be policy neutral, easy to

use, consistent and clean.

The goal of this body of work is to demonstrate the power of operating system

services specific to grid computing. Well designed minimal, policy-neutral operating

1










system services can make a commodity linux operating system highly suitable for

grid computing.

In chapter 2, we describe the motivation behind this work. Details of previous

work and an overview of current trends are provided.

A clean design plays an important role in adding flexible and powerful services

to an existing operating system. Chapter 3 gives a detailed descripting of our

design process. Our design principles and motivation behind choosing a layered

architecture are explained. GridOS consists of four core modules including high

performance i/o, resource management, process management and communication.

Design considerations for each module are detailed.

Chapter 4 provides details of implementation. We developed the modules

as kernel modules using Linux 2.4.19 kernel. Linux kernel module architecture is

exploited to provide easy loading and unloading of the module. Specific details on

implementing the ftp modules with details on module activation and de-activation

are provided. We also developed middleware to ease the process of writing an

application that uses GridOS services.

Chapter 5 shows various scenarios of GridOS usage. The chapter gives a

pictorial view of GridOS operations.

Our experiments indicate that GridOS outperforms the standard ftp and

GridFTP. Details about the experiments and graphs showing performance compari-

son of GridOS with basic FTP and GridFTP are in chapter 6.

We conclude with possible ideas for future work and improvements that can be

done to GridOS.
















CHAPTER 2
MOTIVATION

This chapter presents the motivation behind this thesis. It provides an

overview of grid computing and current trends in grid computing. The most

prominent grid middleware Globus and Condor are explained briefly.

2.1 The Grid

Distributed computing has fascinated researchers all over the world for past

two decades. Traditionally the focus has been on developing a unified homogeneous

distributed system. Recently, there has been tremendous growth in wide area

distributed computing leading to grid conliiilii.:[l1].

The term Grid is chosen as an analogy to electric power grid that provides

consistent, pervasive, dependable, transparent access to electricity, irrespecitve of

type and location of source. The primary focus in Grid computing is to harness

the power of geographically distant supercomputers, and convert them into a big

computing resource.

The Grid enables -h.iiin.:. selection and .-. -:-regation of various resources

including raw cpu cycles, storage systems, data sources and special services like

application servers, etc. These resources may be geographically dispersed, operated

by different organizations with different policies running on completely different

operating systems.

Due to the recent explosion of Grid Technologies, there has been some confu-

sion over the exact nature of a Grid. Dr. Foster provides a three point checklist[5]

for evaluating grid systems.










A grid is a system that


coordinates resources that are not subject to centralized control A Grid
integrates and coordinates resources and users that live within different
control domains for example, the user's desktop vs. central computing;
different administrative units of the same company; or different companies;
and addresses the issues of security, policy, ].r-i ini i. membership, and so
forth that arise in these settings. Otherwise, we are dealing with a local
management system.
uses standard, open, general-purpose protocols and interfaces A Grid is built
from multi-purpose protocols and interfaces that address such fundamental
issues as authentication, authorization, resource discovery, and resource
access. It is important that these protocols and interfaces be standard and
open. Otherwise, we are dealing with an application-specific system.
delivers nontrivial qualities of service A Grid allows its constituent resources
to be used in a coordinated fashion to deliver various qualities of service,
relating for example to response time, throughput, availability, and security,
and/or co-allocation of multiple resource types to meet complex user de-
mands, so that the utility of the combined system is significantly greater than
that of the sum of its parts.

Grids are composed of VO( Virtual Organization)s, a conglomeration of network

resources consisting of servers, desktop PCs, mainframes, clusters, etc. These VOs

are managed by different organizations and may have different policies and security

mechanisms. Grid enables sharing of resources between these heterogeneous VOs

with a common set of open protocols.

There are enormous opportunities for application writers to exploit the large

amount of computational and storage resource provided by the grid.

2.2 Grid Applications

Grid applications typcially involve large-scale scientific computing that

requires huge amount of cpu and data processing resources. The Grid Computing

paradigm allows these huge applications to run smoothly. There are three classes of

applications: compute intensive, data intensive and mixed applications.

Compute intensive applications such as finite element analysis, computational

fluid dynamics, and design-of-experiment (DOE) simulations often require a large







5

amount of CPU power. These applications can easily be parallelized and can be run

on the grid.

Data intensive applications require large inputs and produce huge amounts of

data (sometimes on the order of petabytes). Various scientific applications, includ-

ing High Energy Physics(HEP), Biology and Medical and Earth Observations(EO)

applications, analyze and derive large amounts of data. There is also a growing

need to share this data among various scientific communities. The communities

of researchers are often large and geographically distributed, as are the computing

and storage resources used to analyze the data. The data grid[6] provides a way of

managing this distributed data in a seamless way.

Some applications are both compute and data intensive.

2.3 Grid Middleware

To achieve the goals of the Grid, existing technologies are extended and various

new technologies are developed. These technologies provide a framework to do

various Grid operations with minimum interaction with underlying platform,

architecture and operating system.

Grid middleware provides facilities to use the grid for applications and

users. Middleware like Globus[2], Legion[3] and UNICORE[4] provide software

infrastructure to tackle various challenges of computational and data grids. Data

middleware, which usually is part of general purpose grid middleware, provides

facilities for data management.

Various middleware products have been developed in recent years that are

widely in various scenarios. In their earlier versions, grid middleware provided

incompatible methods to access, manipulate and store the data. The Open Grid

Services Architecture(OGSA) [7] defines the standard communication protocols

and formats for building truly interoperable grid systems. The Open Grid Services

Infrastructure(OGSI) [8] provides the specification for building various grid services










envisioned in OGSA. These specifications have standardized grid services describing

how they operate and interact. OGSI provides detailed WSDL specifications for

standard interfaces that define a grid service.

The third version of the Globus toolkit (GT3) provides implementation of

OGSI specification and provides various OGSI-compliant basic services including

managed job service, index service and reliable file transfer service (RFT). GT3

also provides higher level data services including RLS (Replica Location Service).

The data management services RFT and RLS provide the basic mechanisms for

data management.

In the following sections, we explore popular grid middleware products and

their architectures.

2.4 Globus

Globus[2] provides a software infrastructure that enables applications to handle

distributed heterogeneous computing resources as a single virtual machine. The

Globus project is a U.S. multi-institutional research effort that seeks to enable the

construction of computational Grids. A computational Grid, in this context, is a

hardware and software infrastructure that provides dependable, consistent, and

pervasive access to highend computational capabilities, despite the geographical

distribution of both resources and users. Globus provides basic services and

capabilities that are required to construct a computational Grid. The toolkit

consists of a set of components that implement basic services, such as security,

resource location, resource management, and communications.

It is necessary for computational Grids to support a wide variety of applica-

tions and programming paradigms. Consequently, rather than providing a uniform

programming model, such as the object-oriented model or message-passing model,

the Globus provides a bag of services from which developers of specific tools or

applications can use to meet their own particular needs. This methodology is only










possible when the services are distinct and have well-defined interfaces (APIs) that

can be incorporated into applications or tools in an incremental fashion.

Globus is constructed as a layered architecture in which high-level global

services are built upon essential low-level, core local services. The Globus toolkit

is modular and an application can exploit Globus features, such as resource

management or information infrastructure without using Globus communication

libraries.

Before we try to understand the Globus architecture, let us have a quick look

at the layered grid architecture. Figure 2-1 shows the layered structure of the grid

architecture.

Grid Applications

globus-url-copy High Level Grid Service:

GridFTP Low Level Grid Services

TCP Condor Local Services

Figure 2-1: Layered grid architecture


As we can see, the applications can use high-level tools like globus-uri-copy

or use the low level libraries like globus_ftp_client.

The Globus toolkit is divided into three pillars. Each pillar represents a

primary component that addresses various aspects of grid computing.

All the components use GSI (Grid Security Infrastructure)[9] for security at

the connection layer. Each of these components has a primary protocol provid-

ing the basic functionality. GRAM (Globus Resource Allocation Manager) [10]

implements a resource management protocol, MDS (-\I l.., -iimputing Directory

Service)[11] implements an information services protocol, and GridFTP[12] imple-

ments a data transfer protocol.










2.4.1 Security

GSI provides a security framework for Globus. All other components use this

layer to connect to the world. It provides various features which are important and

necessary in a grid environment


Secure authentication and authorization: GSI provides features to securely
authenticate a user and authorize access to resources
Single sign-on: One of the problems associated with distributed systems is
the task of authenticating a user on each system that he/she wants to execute
a task. GSI provides single sign-on using which a user has to authenticate
only once and his proxy can execute tasks in various administrative domains.
The proxies have a limited lifetime to avoid compromise of credentials.
IntU i'..-' *i1'..:1':l with local security solutions: Usually VOs have different local
security policies within their domain. GSI provides mechanisms to translate
between inter domain security operations and local mechanisms.
Uniform credentials/certification: GSI uses X.509 certificate data format and
public key encryption for user credentials. Users have to obtain a certificate
to access Globus resources.

2.4.2 Data Management

In scientific experiments, efficient data management plays an important role.

These applications access and analyze large amounts of data (sometimes of the

order of peta bytes) and require high-performance and reliable data transfers.

Globus provides GridFTP, a high-performance, secure, and reliable data transfer

protocol optimized for high-bandwidth wide-area networks. GridFTP extends the

popular FTP with features like multiple TCP streams, striped data transfers, etc.

Some of the features are


Secure data transfer: GridFTP uses GSI to provide secure data transfer
mechanisms
Parallel data transfer: Multiple TCP streams are used to efficiently utilize the
high bandwidth of wide-area networks.
Partial data transfer
Third hiil i data transfer: Data can be transferred from a server to another
server using third party control.










Striped data transfer: This is an important feature which allows data to be
partitioned across multiple servers. As a result, with efficient data partitions,
.i- i---regate bandwidth can be greatly improved.

2.4.3 Resource Management

Resource management is an important component of a grid. Globus provides

features to allocate and use resources. Resource management component consists of

three main components


RSL (Resource S, .. :-,l.':-n Language): RSL provides a common language
used by all the components in resource management architecture to perform
their functions. A user uses RSL to specify resource requirements, e.g.
executable = globus-url-copy
GRAM (Globus Resource Allocation Miw,/,; i): GRAM manages allocation
of resources for execution of jobs. It provides a standard interface to local
resource management tools like LSF, Condor etc. Users can query GRAM to
get the status of their submitted jobs.
DUROC (Dynamically Updated Request Online Co-allocator): Co-allocation
is the process of allocating multiple resources at various sites required by
grid applications. This is an important aspect of grid computation. DUROC
provides an API to allocate resources in multiple sites.

2.4.4 Information Services

The Globus information service is called Metacomputing Directory Ser-

vice(\ )S). It provides means of disco.. i iin:. characterizing and monitoring

resources and services in a heterogeneous environment. MDS uses LDAP for

providing uniform access. MDS has two main components


GRIS (Grid Resource Information Service): GRIS provides uniform means
of querying resources for their current configuration, capabilities, and status.
This is used by GRAM to provide status of jobs to the user. GIIS (Grid
Index Information Service): GIIS can be used to discover resources matching
a criterion. It provides a coherent system image of the grid that can be
explored by applications.










Globus can be thought of as a Grid computing framework based on a set of

APIs to the underlying services. Globus provides application developers with var-

ious means of implementing a range of services to provide a wide-area application

execution environment.

2.5 Condor

The Condor[13] project started as providing a framework for high throughput

computing. It provides a framework for workload management in a pool of work

stations. Condor allows effective utilization of available cpu cycles by detecting

idle workstations. Condor provides a job queueing mechanism, scheduling policies,

priorities, resource monitoring and resource management. It is often used as local

scheduler within a virtual organization. In this section, we briefly look at various

features provided by Condor.

Some of the features provides by Condor include


Framework for Opportunistic Coimipu/till: Opportunistic Computing is the
utilization of all the available resource without requiring 100% availability.
Condor effectively harnesses the available CPU cycles by sending jobs to
idle workstations. It provides qii. idiir-. scheduling and planning facilities to
achieve this.
ClassAds: ClassAds[14] provide a mechanisms for match-making. Both
Buyers and Sellers of resources publish a ,1 / 1.;--r./ advertisement and
Condor's MatchMaker matches the requests with available resources. The
MatchMaker eaipl'' a simple matching algorithm that follows the constraints
and policies specified in the advertisements. A ClassAd example is shown in
figure 2-2.
CI 1 ., lY.:/i: and Migration: When users start using idle workstations,
sometimes it is necessary to move the running jobs to other available idle
workstations. This requires checkpointing and migration facilities. Condor
provides these features with some constraints. When a job needs to be
migrated, Condor creates a snapshot of the job called a checkpoint, which
includes detailed account of process state. When the job is re-started on
another machine, the checkpoint file is used to re-create its state. Programs
have to be re-linked with the Condor checkpointing libraries to exploit this
feature.

























[

Type = "Job";

Owner = "ppadala";

Universe = "Standard";

Requirements = (other.OpSys == "Redhat Linux" && other.DiskSpace > 500M);

ClusterID = 1234;

JobID = 0;

Env = ""

Groups = {"condor", "griphyn"};

Files = { [ name = "simulation_data.txt", type = "input"],

[ name = "analysis.dat", type = "output"] }



I


Figure 2-2: A ClassAd example










Split Execution System: Condor provides interposition agents so that a
program executing on a remote system can transparently make a system
call to the originating system. This is useful in running legacy applications
unmodified on a remote system.
Condor-G: A Computation Moino-rirnfit Agent for Grid Coimiiutifi/r.l: Condor-
G provides facilities to combine Condor and Globus technologies. Condor
can be used both as a frontend and backed to Globus toolkit mechanisms.
It provides a consistent interface to submit jobs to resources managed in
different ways.

2.6 Legion

Legion[3] is an object-based meta computing system that envisions providing a

virtual world-wide computer view to the user. Using Legion, users see a single com-

puter with enormous resources. Groups of users can construct a virtual workspace

to collabarate and access resources. Legion sits on top of user's operating system

and using its scheduling and resource management algorithms provides this view.

Legion provides various features including


Object-based Meta System: Legion provides an object-based meta system
in which core objects like host objects and vault(storage) objects. The core
objects provide the basic framework for building advanced services. Every
thing in Legion is an object and the objects are persistent. Users can create
new classes that allows a powerful mechanism to extend Legion capabilities.
Legion File System: Legion file system is developed to cope with the diverse
requirements of wide-area collabarations. It provides a fully integrated
architecture that provides location independent i.iiin. security, scalability,
extensibility and adaptability.
Resource M.n.ii. idi. :l Services: Legion provides an object-based resource
management system that allows user-defined schedulers. The resource model
contains basic resources (hosts and vaults), the information database (the
Collection), the scheduler implementor (the Enactor) and an execution
monitor. See [15] for more details on these components.

2.7 Previous Work

The primary motivation for this work comes from chapter twenty of the book

The Anatomy of the Grid: Enabling Scalable Virtual Organizations, edited by Ian

Foster et al[l], in which the authors discuss the challenges in the operating system










interfaces for grid architectures. The book discusses various principles but stops

short of implementation details.

While there has been little work on Grid Operating System interfaces, there

has been tremendous development in grid middleware. Projects like Globus and

Legion provide elaborate software infrastructure for writing grid applications.

These tools and libraries have to cope with the existing operating system services

that are not designed for high-performance computing. As a result, they are forced

to implement some commonly used high-performance optimizations like multiple

TCP streams and TCP buffer size negotiation that more suitably should be

implemented in the operating system's kernel. These tools, though quite different,

often use the same set of low-level services like resource management, process

management, and high-performance I/O. For example, both Globus and Legion

have to query the operating system for resources and maintain information for

effective resource management. As there is no operating system support for these

low-level services, middleware developers must implement them from scratch. This

is error prone and often results in sub-optimal solutions.

There have been some attempts to add operating system services that perform

high performance computing. WebOS[16] provides operating system services for

wide area applications provides services for wide area applications. PODOS[17],

a performance oriented distributed operating system, is similar and provides

high performance through optimized services in the kernel. This work succeeds

in providing high performance. But due to the extensive changes made to the

kernel, it is difficult to port this work to newer kernels. It is also difficult to extend

the services due to its monolithic structure. GridOS addresses these problems by

providing a modular architecture that requires minimal changes to the kernel and

makes it easy to extend the services.







14

Apart from the above mentioned work, there has been great amount of

research done in distributed operating systems. Systems like Amoeba[18] and

Sprite[19] had great impact on the distributed programming paradigm. We have

incorporated some of the principles used in designing these distributed operating

systems in GridOS.















CHAPTER 3
GRIDOS DESIGN

3.1 Core Principles

The following principles drive the design of GridOS. These principles derive

from the fact that the toolkits like Globus require a common set of services from

the underlying operating system.


Modularity. The key principle in GridOS is to provide modularity. The
components of GridOS should be modular and interact with well-defined
interfaces. The Linux kernel module architecture is exploited to provide a
clean modular functionality.
Policy Neutrality. GridOS follows one of the guiding principles of design of
operating systems: policy-free mechanisms. Instead of providing a black box
implementation that takes care of all possibilities, the modules provide a
policy-free API that can be used to develop high level services like GridFTP.
Higher level middleware, having more information about the application
should be able to setup policies using GridOS APIs.
U':. i -,.i:l. of Infrastructure. GridOS provides a basic set of services that
are common to prevalent grid software infrastructures. It should be easy to
build radically different toolkits like Globus (a set of independent services)
and Legion (an object-based roI I.1--I-I' 1- infrastructure).
Minimal Core Operating System Changes. We do not want to make extensive
modifications to the core operating system as that would make it difficult to
keep up with new OS versions.

These guiding principles led us to develop a layered architecture (Figure

3-1). The lowest layer contains the primary GridOS modules that provide high-

performance grid computing facilities. These modules are orthogonal and provide

basic mechanisms. They do not mandate any policies. The upper layers provide

specific services similar to GridFTP, GASS[20].

This approach is motivated by the observation that the toolkits usually

make policy decisions on behalf of the grid applications. The toolkit, knowing the


































Figure 3-1: M.,i.Pr modules and structure of GridOS


application requirements and having domain knowledge, can make a better decision

about what policy to eil'l 'v. This also encourages a wide variety of toolkits to be

developed on top of GridOS.

The GridOS core services are provided by an iocti and system call interfaces.

A library called libgridos is developed to provide wrappers to the low-level

interfaces. Various kinds of middleware can be developed on top of the library.

Toolkit developers should normally be able to use the libgridos API for accessing

GridOS services.

3.2 Core Modules

In the following sections we describe GridOS modules. We explain the imple-

mentation details in a later chapter.


***IMidI-f- -










3.2.1 gridos-io: High-Performance I/O Module

High performance I/O is an important aspect of grid applications. This

module provides High-Performance network I/O capabilities for GridOS. In an

increasing number of scientific disciplines, large amounts of data (sometimes on

the order of petabytes) are accessed and analyzed regularly. For transporting these

large amounts of data, high-speed WANs are used. These networks have high

bandwidth and large round trip times (RTT), sometimes referred to as "Long Fat

N. I .. i.-" (LFNs, pronounced "elefan(t)s") [21].

In order to take full advantage of these high speed networks, various operating

system parameters must be tuned and optimized. Several techniques for achieving

high-performance are outlined below. It is important to realize that some of these

techniques are not additive, but rather complementary. Applying a single technique

may have little or no effect, because the absence of any one of the techniques can

create a bottleneck.

No User-Space Copying. A user-space FTP server requires the kernel to copy

the network buffers to user-space buffers to retrieve data from the client. It then

requires the kernel to copy the user-space buffer to file system buffers to write data

to a file. This incurs a large overhead due to time spent in copying.

Because gridos_io and gridosftp are kernel modules that handle both

network and file system I/O, thus double copying can be avoided.

TCP WAN Throughput. TCP (Transmissions Control Protocol) [22] is the

standard transport layer used over IP networks. TCP uses the congestion window

(CWND), to determine how many packets can be sent before waiting for an

acknowledgment. On wide area networks, if CWND is too small, long network

delays will cause decreased throughput. This follows directly from Little's Law[23]

that


WindowSize = Bandwidth Delay










The bandwidth is the bandwidth of the slowest link in the path. This can

be measured with tools like pipechar and pchar. The delay can be measured by

calculating the round trip time (RTT) using ping or traceroute.

The TCP slow start and congestion avoidance algorithms determine the

size of the congestion window. The kernel buffers are allocated depending on the

maximum size of the congestion window.

To get maximal throughput it is essential to use optimal TCP send and receive

kernel buffer sizes for the WAN link we are using. If the buffers are too small, the

TCP congestion window will never fully open up. If the buffers are too large, a

fast sender can overrun a slow receiver, and the TCP window will shut down. The

optimal buffer size for a link is bandwidth RTT[24, 25]

Apart from the default send and receive buffer sizes, maximum send and

receive buffer sizes must be tuned. The default maximum buffer size for Linux is

only 64KB which is quite low for high-speed WANs.

The gridos_io module provides various ways of controlling these buffer sizes.

Using the gridos system call, default values for the buffers can be specified. This

may be done by the system administrator who has knowledge about the networks.

gridosio measures the throughput from time to time and updates the buffer sizes

accordingly.

3.2.2 gridos-comm: Communication Module

Communication is an important aspect of a distributed application. Often

applications require various modes of communication depending on the underlying

medium, destination and target application. For example, an application trans-

ferring a huge file requires the network pipe to be full and wants to utilize all the

available bandwidth. On the other hand, an application using MPI calls to commu-

nicate with jobs distributed over a wide area network, requires a quick delivery of

short messages.










The Foster et al. summarizes the requirements for multiple methods of

communication in [26]. Our interpretation of these requirements in the context of

GridOS is as follows.


Separate specication of communication interface and communication method:
Various communication methods are used to send and receive messages.
For example, TCP/IP networks provide reliable (TCP) and un-reliable
(UDP) communication mechanisms. But, the interface to these low-level
communication primitives need to be consistent and should be separate from
the underlying mechanisms. Globus and Legion toolkits already achieve
this but with considerable difficulty. GridOS offers consistent primitives to
asynchronous, synchrnous and reliable, unreliable communications.
Automatic selection: Automatic selection of communication heuristics is re-
quired for ease of programming. Though this is in the domain of middleware,
GridOS tries to select appropriate communication mechanism using simple
heuristics. Note that all the parameters of GridOS can be manually selected
by the middleware layer as explained below.
Manual selection: Grid middleware should allow the user to manually
select communication methods. The middleware requires manual selection
primitives from underlying system like GridOS.
Error Hi ii,1: i & Feedback: Method specific feedback is required in some ap-
plications. For example, a multimedia application might want to know about
the jitter and frame loss rate so that it can optimize the communication.
GridOS provides this information to the middleware through well-defined
interfaces.

The communication module is designed so that middleware writers can provide

multiple communication methods that support both automatic and programmer-

assisted method selection. Grid applications are heterogeneous not only in their

computational requirements, but also in their types of communication. Different

communication methods differ in usage of network interfaces, low-level protocols

and data encodings and may have different quality of service requirements. This

module allows communication operations to be specified independent of methods


used to implement them.










The module also provides multi-threaded communication which is used in

implementing the FTP module. Using the library, various high-level mechanisms

like MPI (M\I --.,ge Passing Interface) [27] can be easily implemented.

3.2.3 gridos-rm: Resource Management Module

Grid systems allow applications to assemble and use collections of resources on

an as-needed basis, without regard to pir, -i .l1 location. Grid middleware and other

software architecture that manage resources have to locate and allocate resources

according to application requirements. They also have to manage other activities

like authentication and process creation that are required to prepare a resource to

use. See [10] for details on various issues involved in resource management.

Interestingly, these software infrastructure use a common set of services.

Gridosrm provides these facilities so that software infrastructure can be developed

to address higher-level issues like co-allocation, online-control etc.

The module provides facilities to query and use resources. The module

maintains information about current resource usage of processes started by local

operating system and GridOS modules. It also provides facilities to reserve

resources. These facilities can be used to develop systems like Condor[13], which

discovers idle resources on a network.

3.2.4 gridos_pm: Process Management Module

This module allows creation and management of processes in GridOS. It

provides a global PID (GPID) for every process in GridOS and provides com-

munication primitives which can be used on top of gridos_comm for processes to

communicate among lli. III,-1' -[2].

This feature allows disparate toolkits like Condor and Globus to use a common

mechanism for creating processes and pass process ids. The global PID is created

by combining the host identifier and local process id. The module also provides










services for process accounting. This feature is important in accounting for the jobs

which are transported to GridOS.

3.3 Additional Modules

3.3.1 gridos_ftp_common

This module provides facilities common to any FTP client and server. This

includes parsing of FTP commands, handling of FTP responses etc.

3.3.2 gridosftpserver

This module implements a simple FTP server in kernel space. Due to its

design, copying of buffers between user and kernel space is avoided. The server

does not start a new process for each client as is usually done in typical FTP

servers. This incurs low overhead and yields high-performance. The server also uses

gridos_io facilities to monitor bandwidth and adjust the file system buffer sizes.

The file system buffers are changed depending on the file size to get maximum

overlap between network and disk I/O.

The module is designed with security in mind. Even while operating in

the kernel mode it drops all privileges and switches to an unprivileged user-id

and group-id. It also chroots to FTP top level directory docroot which can be

configured dynamically.

3.3.3 gridos_ftp_client

This module implements a simple FTP client in the kernel. The main purpose

of this module is to decrease the overhead of writing or reading file on the client

side. Our experiments indicate that primary overhead on the client side is the time

spent in reading and writing files. By carefully optimizing the file system buffers

to achieve maximum overlap between network and disk I/O, high-performance is

achieved.
















CHAPTER 4
IMPLEMENTATION

We have implemented a subset of GridOS on Linux using the stable 2.4.19

kernel. The Linux kernel module architecture is exploited to provide ease of

installation for users and ease of modification for developers. The code is divided

into a small patch to the core kernel and a set of kernel modules. The patch

is designed to be minimal and adds the basic iocti and syscall interfaces to

GridOS.

The modules are inserted and removed using insmod and rmmod utilities. The

dependencies between the modules are resolved using modules.dep. As a result,

if gridos_comm is inserted without inserting gridos_io the kernel would find that

there is a dependency and insert gridos_io automatically.

Currently, we have implemented gridos_io, gridosftp_server, gridosftp_client

and the library wrapper libgridos. We have also implemented a simple middle-

ware called gridos-middleware as a proof-of-concept showing the ease with which

middleware can be developed. The following sections explain the internals of the

modules.

4.1 Linux Kernel Module Architecture

The Linux kernel module architecture provides micro kernel facilities to a

monolithic design. In the olden days, to add features to the Linux kernel, one

had to modify the source and build a new kernel. This is still true for core parts

of the kernel like the scheduler. Loadable kernel modules are developed as a way

of adding non-core features easily into the kernel. Once loaded into memory, the

kernel module becomes part of the running kernel.

22










There are many advantages to using loadable kernel modules. Some of the

advantages are


No need to re-build the kernel. As a result, modules can be added to and
removed from a running kernel without rebooting the machine or compiling a
new kernel.
Easy to diagnose problems. If a loaded driver is causing problems in a
perfectly running kernel, the problem is probably with the driver.
Can save memory. Administrators can unload modules that are not used and
free up memory. Linux provides automatic module loading and unloading as
well.
Provides modularity. Different people can work on various modules without
worrying about making conflicting changes to the kernel.

4.2 Kernel Level Web/Ftp Server (tux)

Tux is an HTTP protocol layer and a web server object cache integrated into

the Linux Kernel. It can be thought of as a kernel-level web server. TUX stands for

Threaded linUX http layer.

Tux is an interesting concept similar to the methods used in High-Throughput

Computing. It provides high-performance web server by avoiding copying of

network buffers between user and kernel mode. Usually web servers are big piece

of software written in user-mode. When the data arrives over network, kernel

copies the data into user-mode buffers from kernel network buffers. When high-

performance is needed, this becomes a bottleneck and may produce lot of overhead.

If the web server is just serving static content, then this copying of data back and

forth from user to kernel mode can be avoided by having a small kernel web server.

Tux fills this gap perfectly by serving static content directly from kernel mode and

leaving dynamic content like CGI to an external web server like Apache.

This section provides a brief overview and code review of Tux. I also indicate

various parts of tux that are used in implementing GridOS modules.










4.2.1 User Level Access to kernel HTTP layer

User processes can access the Tux server by using the systux system call.

Using this system call, user processes (usually the rc scripts) can drive the server.

The caller specifies various actions like startup, shutdown server, start thread etc.


Startup: The startup action sets up TUX data structures depending on the
parameters passed from user mode. These include the number of threads,
buffer sizes, etc.
Shutdown: This action shuts down TUX cleaning up the memory used by
TUX.
Register Module: TUX provides module facilities so that a user can write
a user-mode module to handle specific activity like CGI query handling.
The register action registers a handler that will be called based on a specific
action.
Un-register Module: This action unregisters the module.
Start Tin. n/i-: This is one of the important actions of TUX. TUX does its
own handling of kernel threads. As a result, TUX is much faster than other
similar software using kernel threads.

Figure 4-1 shows relevant code. Note that this code and other code snippets

are simplified for clarity.

4.2.2 Listening & Accepting Messages

The listener threads in tux listens to any requests and accepts the connections.

The function start listening listens on the specified socket and accepts connections

through accept-requests function. The start listening function is used with small

modifications in GridOS to accept incoming connections. Figure 4-2 shows relevant

pieces of code.

An event loop waits for accepted connections. The event loop goes through

all the threads checking for pending connections requiring processing. Once an

accepted connection is found, it removes it from the accept queue and processes the

content of request. Figure 4-3 shows the event loop.

The proto->got_request is the function httpgotrequest which calls parserequest.

parserequest calls parse-message which will parse the message and finally calls














switch (action) {
case TUXACTIONSTARTUP:
lock_kernel();
ret = user_req_startup();
unlock_kernel();
goto out;

case TUXACTIONSHUTDOWN:
/* code similar to above */

case TUXACTIONREGISTERMODULE:
ret = user_register_module(u_info);
goto out;

case TUXACTIONUNREGISTERMODULE:
ret = user_unregister_module(u_info);
goto out;

case TUX ACTION STARTTHREAD:
{
unsigned int nr;

/* get the number of threads */
ret = copy_from_user(&nr, &u_info->thread_nr,
sizeof(int));
error_handling;

ti = threadinfo + nr;

/* stuff added to process structure */
current->tux_info = ti;
current->tux_exit = tux_exit;

lock_kernel();
/* the real thing */
ret = user_req_start_thread(ti);
unlock_kernel();

/* after returning set tux_info and tux_exit to null */
}
}


Figure 4-1: Tux actions




















struct socket start_listening(tux_socket_t *listen, int nr)
{
err = sock_create(PF_INET, SOCK_STREAM, IPPROTO_TCP, &sock);
if (err < 0) {
goto err;
}

/* Bind the socket: */
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(addr);
sin.sin_port = htons(port);

sk = sock->sk;
sk->reuse = 1;
sk->urginline = 1;

#define IP(n) ((unsigned char *)&addr)[n]
err = sock->ops->bind(sock, (struct sockaddr*)&sin, sizeof(sin));
if (err < 0) {
goto err;
}

/* sk structure contents are filled with appropriate values
for performance gain. */
err = sock->ops->listen(sock, tux_max_backlog);
if (err) {
goto err;
}
return sock;

error_handling;
}


Figure 4-2: Connection accept























switch (action) {

case TUXACTIONEVENTLOOP:
eventloop:
req = ti->userspace_req;
if (req)
zap_userspace_req(req);
ret = event_loop(ti);
goto out_userreq;





}
static int event_loop (threadinfo_t *ti)
{



set_task_state(current, TASK_INTERRUPTIBLE);
work_done = 0;
if (accept_pending(ti))
work_done = accept_requests(ti);




}


Figure 4-3: Event loop


















* Puts newly accepted connections into the inputqueue. This is the
* first step in the life of a TUX request.

int accept_requests (threadinfo_t *ti)
{




tpl = &sock->sk->tp_pinfo.af_tcp;

Quick test to see if there are connections on the queue.
This is cheaper than accept() itself because this saves us
the allocation of a new socket. (Which doesn't seem to be
used anyway)

if (tpl->accept_queue) {
tux_proto_t *proto;

/* set task state to running */

new_sock = sock_alloc();
error_handling;

new_sock->type = sock->type;
new_sock->ops = sock->ops;

error = sock->ops->accept(sock, new_sock, O_NONBLOCK);




proto = req->proto = tux_listen->proto;
proto->got_request(req); /* this will call http_got_request */

}
}


Figure 4-4: Accept request










http_parse_message.

The request functions have been modified in GridOS to handle GridOS specific

connections. Other code in GridOS is written from scratch.

4.3 Modules

4.3.1 Activation

The modules activation and de-activation is done with usual insmod and

rmmod commands. Apart from the basic module dependency features provided by

the Linux kernel, I developed a mechanism to check whether a required GridOS

is moduled is loaded. Each GridOS module after startup updates a global kernel

structure (after taking care of the synchronization issues). When a GridOS module

starts up, it checks whether all core modules are present or not. Then, it checks for

the existence of required additional modules.

4.3.2 10 Module

The globus 10 module implementation is divided into two APIs, one each

for the network and the file system. The 10 module is designed to minimize copy

operations and let the data flow remain within the kernel.

The network API includes functions to read and write data from a gridos

managed socket. Both blocking and non-blocking read calls are provided. Gridos

FTP modules make extensive use of non-blocking reads for high-performance. It

also has functions to set various buffer management options.


gridos-io-- qi, _read: This function is used to read data from a gridos managed
socket in blocking mode.
gridosio-> i-il, _read: This function is used to read data from a gridos
managed socket in non-blocking mode
gridos-io-write: This function writes data to the gridos managed socket
gridos-io-buffersetopt: This function sets options for buffer management.
The options include setting of TCP send and receive buffer sizes, maximum
TCP buffer size etc.
gridosio-buffergetopt: This function returns the current buffer management
options.










int gridos_io_file_write(const char *buf, const char *dst, int size)
{ struct file *f = NULL;
int flags, len;
mm_segment_t oldmm;
int mode = 0600;

flags = 0_WRONLY;
if(!dst) {
printk(KERN_ERR "Destination file name is NULL\n");
return -1;
}
f = filp_open(dst, flags, mode);
if (!f |I !f->f_op |I !f->f_op->write) {
printk(KERN_ERR "File (write) object is NULL \n");
return -1;
}
f->f_pos = 0;

oldmm = get_fs(); set_fs(KERNEL_DS);
len = f->f_op->write(f, buf, size, &f->f_pos);
set_fs(oldmm);
if (f->f_op && f->f_op->flush) {
lock_kernel();
f->f_op->flush(f);
unlock_kernel();
}
fput(f);
printk(KERN_INFO "Wrote %d bytes\n", len);
return len;
}

Figure 4-5: File write function listing


The file system API has similar functions for reading and writing data to files.

These functions call the Linux Kernel's VFS (Virtual File System) functions to

achieve this. Here is some sample code showing implementation details (simplified

for clarity)

The file system API also has a higher-level function gridosfile_copy which

can be used to copy a file locally. This can be used for high-performance local

copying of files.










gridos-io also has facilities to compressed gzip data stream. This can be

configured by setting the compression option.

4.3.3 FTP Client and Server Modules

The FTP server API allows the user to create an FTP server on a specified

port. Various configuration options like docroot (top level directory for {iii','iii'."ii-

FTP) threads (number of simultaneous threads) etc can be set to control the

behaviors of FTP module. Dynamic configuration can be done via Linux's sysctl

mechanism. This provides access to FTP module features through /proc interface

which can be used to read and modify various variables in the kernel address space.

Threading Model. For high performance kernel threads are used to satisfy

simultaneous connections. The thread model has been adapted from TUX, a kernel

web server. The model is similar to the FLASH web -' I.- I [29] where requests are

handled simultaneously while managing any disk I/O asynchronously in separate

threads.

There are two thread pools. The first pool of threads is I/O or cache-miss

thread pool. These threads populate the buffers asynchronously at the request

of listener threads. The number of I/O threads can be changed by setting the

numthreads configuration option. All the threads are started at the start of

gridos_ftp_server module.

The second pool of threads is fast or listener threads. These threads handle

requests and send responses to clients.

4.4 Library Wrapper

There are three ways of controlling gridos behavior from user-space.


Through system call sysgridos
Using ioctl on gridos device
Using /proc interface










libgridos provides an i..-v-to-use interface to these three low level interfaces.

Currently, C function wrappers are provided to


Read and write from/to the network
Read and write from/to files
Set configuration options
Start and Stop FTP server
Use the FTP client

4.5 GridOS Middleware

One of our design goals is to ease the development of middleware like Globus.

We have developed a small middleware prototype, which provides uniform access to

files whether they are located remotely or locally. The operations are similar to the

operations provided by Globus GASS. We developed this library in just a few days

and it shows how easy it is to develop middleware using GridOS.

Various kinds of applications can be developed using the middleware.
















CHAPTER 5
SCENARIOS

5.1 Scenario #1: Transporting a file

In this section, we show module interaction while transporting a file. The

file transporting is initiated by a user-space application like gridos-middleware

that uses sys_gridos. Depending on the parameters various GridOS modules do

the required work. In this case gridos_ftp_client calls gridos_io-fileread

which reads the file into file system buffers. The buffers are used directly to

initiate the network 10. On the server side the network buffers are handed over to

gridos_ftp_server which can initiate a file writing with gridos_iofile_write.

Figure 5-1 shows the scenario in detail. The process of starting the ftp server is not

shown in the figure.

In comparison, figure 5-2 shows file transfer using a normal ftp client and

server. In this scenario, you can see that double copying is done between user-mode

and kernel-mode. In the GridOS scenario double copying is avoided by handling the

transfers within the kernel.

5.2 Scenario #2: Reading and Writing to a file locally

In this scenario, we show the usage of gridosifile_copy that can be used

to copy a file locally. As there is no copying between user and kernel mode, the

performance is improved. Figure 5-3 shows the scenario in detail.























User Mode


L I .- --III I IdI I .


"^r I


Kernel-Mode







VFS gridos_io







n


Network


Client Server


sysgridos
gridos_io_file_read
generic_file_read
gridos_ftp_ listen
gridosio_file_write
generic file write


gridos_io VFS









control
data


Figure 5-1: Transporting a file using GridOS


Figure 5-2: Transporting a file using normal FTP client and server


1 read from file
2- write to socket
3 generic_file read
4 read from socket
5 wnte to file
6 genenc filewrite


contml
data


























m iht I11i lJl k'\ \.irt'


1 sys_gridos
2- generic file_read
S 3- generic file_write


j


control


Figure 5-3: Reading and writing to a file


User Mode

Kernel-Mode
















CHAPTER 6
PERFORMANCE

We have conducted various experiments to measure the performance of GridOS

comparing it to standard OS services and Globus services. The use of GridOS

services results in a dramatic increase in throughput in our experiments. First,

we compare ftp performance using GridOS and the standard proftpd shipped

with Mandrake Linux, which showcases the advantages of zero-copy I/O. Then,

we compare performance of transporting a file using GridFTP server and GridOS

ftp using globus-url-copy as the client. This reveals an important bottleneck in

high-performance I/O: file writing overhead. Finally, we compare performance of

file transfer using GridOS ftp client and server and globus-url-copy and GridFTP

server.

The experiments confirm that on average GridOS is 4 times faster than ftp and

1.5 times faster than GridFTP.

6.1 Test Environment and Methodology

The tests are conducted in an experimental grid setup in the self-managed

network of CISE at UFL. Globus toolkit version 2.2 is used for setting up the grid.

The two testing machines were connected over 10OMbps Ethernet network. The

machines were kept idle while running the tests so as not to allow other processes

running on these machines affect the performance numbers.

In each experiment files of sizes varying from 1KB to 512MB were used and

the total time taken to transport each of these files was calculated. For each

transfer the average of 5 runs for each file was taken. To avoid the affects of serving

from the cache, the testing machine was rebooted after each run.

36











u8



25
.E 4

C,


1k 4k 16k 64k 256k im 4m 16m 64m 256m
File Size

-4-GridOS -*--Proftpd


Figure 6-1: GridOS vs Proftpd using standard ftp client


7

M5

3
C2

0 0 o



File size

---GridOS -*-GridFTP


Figure 6-2: GridOS ftp vs GridFTP using globus-url-copy as client


6.2 GridOS vs Proftpd

In our first experiment, we compared the performance of the proftpd and

GridOS ftp servers using the standard ftp client shipped with Mandrake Linux

as the client. Results are shown in figure 6-1. This experiment show-cases the

advantages of serving the files from within the kernel. GridOS consistently performs

better than Proftpd for all file sizes.











10
8
a6
'Z: 4-



0 0 \ \ C0 (

File size

---GridOS server/client -H-GridFTP server/globus-url-copy


Figure 6-3: GridOS ftp server/client vs GridFTP server/globus-url-copy


6.3 GridFTP vs GridOS ftp server using globus-url-copy client

This experiment was done using the globus-url-copy client for a fair com-

parison. Results are shown in figure 6-2. GridFTP performs poorly for small files

due to the overhead incurred in the performing security mechanisms. GridOS ftp

employs the standard ftp password authentication for security.

We also conducted experiments using the standard ftp client instead of globus-

url-copy for GridOS. Performance was poor compared to the performance obtained

using globus-url-copy. Globus-url-copy is specifically designed for high-performance

computing and has better buffer management. This led us to develop an in-kernel

ftp client.

6.4 GridFTP server/client vs GridOS ftp server/client

In this experiment, globus-url-copy and gridos-ftp-client are used as

clients for GridFTP and GridOS ftp server respectively. GridOS ftp client makes

effective buffer management and is designed on the same lines as globus-url-copy.

Results are shown in figure 6-3. Based on our experiments we observe that the

performance drop for larger files is due to the overhead involved in disk writes.















CHAPTER 7
GRID FILE SYSTEM

In the later days of my thesis work, I started working on development of a grid

file system. The initial idea was to develop file system primitives in the operating

system to provide facilities for higher level middleware. But, as it turned out, the

file system primitives rightly belong to the middleware. In this chapter, motivation

for the work, design and preliminary implementation results are provided.

In scientific disciplines using a grid, there is a growing need to access the data

in the traditional file system semantics. To provide sharing of data generated from

heterogeneous file systems in the grid environment, a logical hierarchical namespace

with associated metadata that allows POSIX operations is required.

Currently, data middleware that are usually part of the general purpose grid

middleware like Globus[2] and Legion[3] provide services for data management.

In their earlier versions, middleware provided incompatible methods to access,

manipulate and store the data. The Open Grid Services Architecture(OGSA) [7]

defines the standard communication protocols and formats for building truly

interoperable grid systems. The Open Grid Services Infrastructure(OGSI) [8]

provides the specification for building various grid services envisioned in OGSA.

These specifications have standardized grid services describing how they operate

and interact. OGSI provides detailed WSDL specifications for standard interfaces

that define a grid service.

The third version of Globus toolkit (GT3) provides implementation of OGSI

specification and provides various OGSI-compliant basic services including managed

job service, index service and reliable file transfer service (RFT). GT3 also provides

39


















user=ppadala user=sanjay
group=uscms group=uflorida
perms=rwxrwx--- perms=rwxrwx---
desc="temporary space"

Figure 7-1: ufl.edu logical structure

root



user=ppadala vdt tmp user=sanjay
group=uscms group=uflorida
perms=rwx------ perms=rwx--x--x
desc="temporary space"
globus condor


Figure 7-2: ucsd.edu logical structure


higher level data services including RLS (Replica Location Service). The data

management services RFT and RLS provide the basic mechanisms for data

management.

A grid application with complex requirements for data management often

requires much more than what is provided by the basic services. Some of the

features required include file or object level locking, automatic replica management

and logical hierarchical name space.

We developed a file system service(FSS) for grids that provides a logical

heirarchical name space that allows POSIX operations.

7.1 Motivating Example

Scientific applications in domains like High Energy Physics, Bioinformatics,

Medical Image Processing and Earth Observations often analyze and produce

massive amounts of data (sometimes of the order of petabytes). The applications

access and manipulate data stored in various sites on the grid. They also have










to distribute and publish the derived data. Let's see a scenario of how a typical

scientific application interacts with the data grid.

1. A p.lr. -i. i-1 participating in a high-energy 1.1. -i. experiment would like to

execute a high energy Ii.1 i. application.

2. The application requires various input files. It has to find the location of files

using a catalog, index or database system where information about location

of the file is stored. The application usually uses a logical file name(LFN) to

index into the catalog and find the pir, -i. .l location.

3. The files may have to be replicated at various places in the grid for the ap-

plication to find a nearby location to quickly access the file. The application

may also have to prefetch the file to a designated site for execution of a job

that requires the file at that site.

4. The jobs execute using the input files and produce derived data.

5. The derived data needs to be sent to various sites on the grid for usage by

other scientists and for archival purposes.

6. Finally, the output data location has to be published in the catalog.

Using current middleware the above scenario requires the application to per-

form complex interactions with grid services. Also the application cannot perform

the usual POSIX operations on a logical name. The application doesn't have full

details of the file system and operations like find all the sites with minimum 100MB

temporary space cannot be performed directly.

Grid File System Service (FSS) provides services that allow an application to

be written in familiar POSIX semantics. Under the hood, FSS performs the above

operations and can optimize the file access.

Each site participating in the grid exports a local file system structure to the

world. This structure is a logical hierarchy as defined by the site administrator.

The logical hierarchy can be mapped to 1.1li--i. .l1 resources in various ways. This
















user=ppadala
group=uscms tmp vdt
perms=rwxrwx---
desc="temporary space"

globus condor

Figure 7-3: Find query result


logical to 1.1li -i. .l1 mapping is maintained in the local LRC (Local Replica Catalog).

Figure 7-1 and 7-2 show logical mapping for two sites ufl.edu and ucsd.edu.

Note that the logical directories do not have to follow the 1]li-,-i. .l1 structure. For

example, /tmp directory on ufl.edu may be mapped to /cise/tmp where as on

ucsd.edu it might be mapped to /export/tmp. An application or user can create an

application- or user-specific view of this global structure by using FSS services.

The following scenario clarifies the usage.

1. A ]'li, -i. i-1 participating in a high-energy 1.1li -i'. experiment would like to

execute a high energy I1.1 i. application

2. The application requests FSS to provide an application specific view on the

global file system. For example, an application requests FSS to provide all the

directories owned by user ppadala. This is similar to a

find -type d -user ppadala -name "*"

command in traditional UNIX file systems.

3. FSS returns a logical hierarchy shown in figure 7-3.

4. Now, the application makes a query on the logical hierarchy to find the

directory with description "temporary -p.' which returns /ufl.edu/tmp.

5. Application creates files in the temporary space using the logical name

provided by FSS. Under the hood, the file is created in the specific site.

6. It closes the file and other applications can see the file.










7. Similarly, an existing file can be found by performing a query. For example,

the user might be interested in all the temporary files created in various sites

so that he can delete them.

Before we delve into the design of FSS, let us investigate the requirements of

a grid file system. I am leading a survey for grid file system requirements for the

GFS-WG (Grid File Systems Working Group) to understand various aspects of

grid file systems. Here we delve into some aspects of the requirements of a grid file

system.

7.2 Requirements

Investigating current middleware used in the data grids and the requirements

for data management in various grid applications, we identified the following

requirements.


Logical Hierarchical Name Space: Since data is stored in different name
spaces in the grid, it is essential to have a universal name space encompassing
underlying naming mechanisms. In a data grid, data might be stored in a file,
collection of files or in a database table. They may be replicated in various
sites for efficiency. A logical hierarchical name space separates the application
from the existing pir, -i. .l file system and provides a familiar tree file system
structure. Replicas and Soft links complicate the structure.
Uniform Storage Interface: The file system should provide a transparent,
uniform interface to heterogeneous storage.
Data Access/Transfer: Robust and flexible mechanisms for data access and
transfer are required.
Replica Milnrinprinrit: Replication is the process of maintaining identical
copies of data at various sites. The main purpose of replication is to maintain
copies of the data at nearby sites thus increasing read performance. But, it
introduces other issues like consistency management and life cycle manage-
ment. The file system should provide basic replica management facilities like
creation, update and deletion of replicas.
I,,/. io ;i Minagrim rt: Usually data for a grid application are distributed
over various sites on the grid. A grid file system should provide mechanisms
for managing the latency using mechanisms like streaming, disk c.r lii:.
pre-fetching and bulk loading.
Metadata Mauniariirm t: Metadata is the data about the data. There are
various kinds of metadata described in detail later. A file system should










provide basic metadata management facilities and support for at least file
level metadata. It should also support mechanisms through which additional
metadata can be managed.
Optimization and Performance: The file system should optimize the data
access/transfer using various methods including data transfer prediction based
on past information. Automatic replica management based on application
access patterns is required.

7.3 Design

In the following sections, we detail the design of the FSS.

7.3.1 Logical Hierarchical Name Space

The logical hierarchical name space is the most important property of FSS.

Each virtual organization or site running FSS can export a logical hierarchy to

the world. The site administrator can decide on any arbitrary logical to 1pl 1-i. .-1

mapping depending on his storage structure. The logical hierarchy is represented

as a tree with nodes having attributes. The nodes have metadata associated with

them. The metadata provides data about file size, creation time, access control

information etc. More details are in section 7.3.4.

An application or user can send a query to local FSS and get a logical view as

a result. This approach is similar to the query-based logical hierarchy proposed in

the logic file system[30].

7.3.2 Data Access/Transfer and Replica Management

FSS builds on top of existing grid services multirft, fi.1' 'in. ri',.i and RLS.

Figure 7-4 shows this layered architecture. The multirft and filestreaming grid

services are used for data access and transfer. FSS uses RLS for basic replica

management providing more complex features like automatic replica management

on top of it.

7.3.3 POSIX semantics

FSS provides a POSIX semantics for accessing the files. It provides the

familiar open, read, write, close operations. An application must first request a










FSS


Figure 7-4: FSS architecture


logical view from the local FSS before it can do these operations. The logical view

is cached by the local FSS with mappings to Ipli -i' .l1 locations for fast access.

Details about the operations are given below.


open: Open takes the file to open and the flags specifying whether the file
should be opened as read-only, write-only, append or read-write. When a
file is opened for writing, a write lock is placed on the file until the file is
closed by the application. Open returns a unique handle that can be used to
perform other operations. Note that the handle is unique only to the local
FSS.
The open request is propagated to the corresponding site FSS and the
metadata corresponding to the particular file is updated. FSS creates a local
disk cache for the file.
read: The read operation can be done on an open handle. The filestreaming
service is used to perform reads at a particular block. Reads are first per-
formed on the local disk cache and if the data is not available in the cache, it
is fetched from the remote site.
write: Write operations write data to an open file. The writes are first done
to the local cache and are propagated to the remote site via a background
process. The filestreaming service is used to propagate writes. All replicas of
the files are also updated.
close: The close operation performs all pending writes, cleans the disk cache
and updates the file metadata.


GT3 base services
(FileStreaming, MultiRFT)


GT3 Core

GT3










Directory operations like mkdir, opendir, readdir, closedir are provided for

manipulating directories.

7.3.4 Metadata

There are many kinds of metadata including file level metadata, storage

metadata, access control metadata, application specific metadata etc. FSS attaches

metadata with each node in the logical hierarchical name space. We defined the

following metadata to be associated with each node in the logical tree.


File Level Meta Data: This metadata describes the information about the file.
This includes size of the file, creation, modification and access time, creator
and locking information.
Access Control Meta Data: This describes the permissions on the file.
Currently, FSS supports traditional user, group, other permissions.
Application SI.., 'I: Meta Data: Scientific applications often associate various
metadata including provenance and derivation information with the files. The
desc(description) attribute shown in the previous examples is used to provide
information about the directory.

There is a lot of potential for associating special purpose, application specific

metadata that can improve the queries.

7.3.5 Automatic Data Management

FSS can perform automatic data management depending on the file access

patterns. For example, replicating a much accessed file (called hot-spot) at various

sites improves performance and can be replicated automatically.

7.3.6 Performance Optimization

FSS opens up lots of possibilities for efficient data management. The logical

views for an application group can be maintained together and can be cached at

the local FSS. It can also be statically stored at a central location like metadata

catalog server.











Aggregation of files as a single file and Distribution of fragments of file provide

mechanisms for efficient distribution of large data. Queries for finding the data can

be optimized and executed by adding additional attributes to the logical hierarchy.

7.4 Building the Service

In this section, we describe our preliminary FSS design. Note that these

descriptions are only preliminary and will be improved over time. Currently, we

have defined description for basic open, read, write, close and getLogicalView

operations. The GWSDL description is shown in appendix 9.

7.4.1 ServiceData

The servicedata will contain elements for specifying the number of managed

files, number of open files and their status.


type="xsd:int"

minOccurs="1"

max0ccurs="1"

mutability="mutable"

nillable="false">



number of managed files

by the service






type="fileStatusType"

minOccurs="1"

max0ccurs="1"

mutability="mutable"

nillable="false">












Status of the file





7.4.2 Notification

Many interesting scenarios can be implemented using the notifications provided

by FSS. Notification for change of files, change of file metadata can be provided.

7.5 Open Questions

There are many open questions to be answered for building the file system

service. Below, We list a questions we are exploring.


How can we share the logical views of an application among various FSS?
What protocol should be used for this federation?
What is the format for logical views that are returned to the application? We
are thinking of returning the view in a XML format. How should one return a
partial view if the results are too big?
How can we efficiently manage the metadata? We are thinking of using the
meta data catalog server that is available at each site for storing metadata of
the files related to that site.
How should we propagate the updates/writes to files and metadata. This
is a big research question involving latency management and consistency
protocols.
What are the approaches for automatic replica management? We are investi-
gating user-initiated, application-initiated, scheduler-initiated and automatic
replica management.















CHAPTER 8
FUTURE WORK

The work presented in this thesis is a first step towards a grid operating sys-

tem that provides extensive, flexible services for grid architectures. Our next step

is to implement all GridOS modules. We have plans to drpl.'.: GridOS in a wide

area computing testbed. It can be used in nationwide test beds similar to GriPhyN

(Grid Physics Network) [31] at the University of Florida. Such environments will

enable use to evaluate GridOS modules more realistically.

There are many possibilities for high level middleware to exploit GridOS

functionality. Globus core libraries can be ported to use GridOS functionality

making them even more powerful. Interesting scenarios like interoperating between

Condor and Globus job IDs using GridOS process management module are worth

exploring.

The Grid File System opens up tremendous opportunities for efficient data

management. Efficient data management techniques like optimal replica selection

mechanisms can be developed using the Grid File System.
















CHAPTER 9
CONCLUSIONS

We have described a set of operating system services for grid architectures.

These services make a commodity operating system like Linux highly suitable for

high-performance computing. We have identified a common set of services that

use grid software infrastructures like Globus, Legion, Condor etc. The services are

developed as a set of modules for ease of use and installation. Our performance

experiments show that high-performance can be achieved with GridOS modules.

We have also described proof-of-concept middleware that uses GridOS facilities.

We presented the design for a grid file system that provides logical hierar-

chical name space, uniform storage interface, replica management and metadata

management.


















APPENDIX
GRID FILE SYSTEM GWSDL DESCRIPTION


attributeFormDefault="qualified"

elementFormDefault="qualified"

xmlns="http://www.w3.org/2001/XMLSchema">








































51


































































































































































































































































































































REFERENCES


[1] I. Foster and C. Kesselman, editors. The Grid: Blueprint for a Future
Co(1,,,putfin,' Infrastructure. Morgan Kaufmann Publishers, San Francisco,
California, 1999.

[2] I. Foster and C. Kesselman. Globus: A metacomputing infrastructure
toolkit. The International Journal of Supercomputer Applications and High
Performance Coimpu/tinl, 11(2):115-128, 1997.

[3] Andrew S. Grimshaw, William A. Wulf, and the Legion team. The legion
vision of a worldwide virtual computer. Communications of the ACI/,
40(1):39-45, January 1997.

[4] V. Huber. UNICORE: A Grid computing environment for distributed and
parallel computing. Lecture Notes in Computer Science, 2127:258-266, 2001.

[5] Ian Foster. What is the grid? A three point checklist. Grid Today, 1(6), July
2002.

[6] A. Chervenak, I. Foster, C. Kesselman, C. Salisbury, and S. Tuecke. The data
grid: Towards an architecture for the distributed management and analysis
of large scientific datasets. Journal of Network and Computer Applications,
23:187-200, 2001.

[7] I. Foster, C. Kesselman, J. Nick, and S. Tuecke. The phi--i. .1. 1- of the grid:
An open grid services architecture for distributed systems integration. Open
Grid Service Infrastructure WG, Global Grid Forum, June 2002.

[8] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman,
T. Maguire, T. Sandholm, P. Vanderbilt, and D. Snelling. Open grid services
infrastructure (ogsi) version 1.0. Global Grid Forum Draft Recommendation,
July 2003.

[9] I. Foster, C. Kesselman, G. Tsudik, and S. Tuecke. A security architecture for
computational grids. In ACM Conference on Computers and Security, pages
83-91. ACM Press, 1998.

[10] K. Czajkowski, I. Foster, N. Karonis, C. Kesselman, S. Martin, W. Smith, and
S. Tuecke. A resource management architecture for metacomputing systems. In
The 4th Workshop on Job S- hdl 1;iii, Strategies for Parallel Processing, pages
62-82. Springer-Verlag LNCS 1459, 1998.










[11] K. Czajkowski, S. Fitzgerald, I. Foster, and C. Kesselman. Grid information
services for distributed resource sharing. In Proceedings of the 10th S,;1,..:;..
on High Performance Distributed Coiiipui/tihni, pages 181-195, 2001.

[12] Bill Allcock, Joe Bester, John Bresnahan, Ann L. Chervenak, Ian Foster,
Carl Kesselman, Sam Meder, Veronika Nefedova, Darcy Quesnel, and Steven
Tuecke. Data management and transfer in high-performance computational
grid environments. Parallel Coiujipitihnl, 28(5):749-771, MI.ir 2002.

[13] M. J. Litzkow, M. Livny, and M. W. Mutka. Condor : A hunter of idle
workstations. In 8th International Conference on Distributed Coimui/ihftinI
S .-n;i-i. pages 104-111, Washington, D.C., USA, June 1988. IEEE Computer
Society Press.

[14] Rajesh Raman, Miron Livny, and Marvin Solomon. Resource management
through multilateral matchmaking. In Proceedings of the Ninth IEEE S;',,:1..'-
sium on High Performance Distributed Coi,,,putihin (HPDC9), pages 290-291,
Pittsburgh, PA, August 2000.

[15] Steve J. Chapin, Dimitrios Katramatos, John Karpovich, and Andrew S.
Grimshaw. Resource management in legion. Technical Report CS-98-09,
Department of Computer Science, University of Virginia, February 11 1998.

[16] Amin Vahdat, Tom Anderson, Mike Dahlin, Eshwar Belani, David Culler,
Paul Eastham, and Chad Yoshikawa. WebOS: Operating system services for
wide area applications. In Proceedings of the Seventh Si:./ <.';.*;: on High
Performance Distributed Coi,,iutiiin, pages 52-64, July 1998.

[17] Sudharshan Vazhkudai, Jeelani Syed, and Tobin Maginnis. PODOS the
design and implementation of a performance oriented Linux cluster. Future
Generation Computer Si-t.-i-. 18(3):335-352, January 2002.

[18] Andrew S. Tanenbaum and Sape Mullender. An overview of the Amoeba
distributed operating system. Operating Si.t. ~i- Review, 15(3):51-64, July
1981.

[19] John K. Ousterhout, A. R. Cherenson, Fred Douglis, Michael N. Nelson, and
Brent B. Welch. The Sprite network operating system. Computer, 21(2):23-36,
February 1988.

[20] Joseph Bester, Ian Foster, Carl Kesselman, Jean Tedesco, and Steven Tuecke.
GASS: A data movement and access service for wide area computing systems.
In Proceedings of the 6th Workshop on I/O in Parallel and Distributed Systems
(IOPADS-99), pages 78-88, New York, M..vr 5 1999. ACM Press.

[21] W. R. Stevens. TCP/IP Illustrated, Volume 1; The Protocols. Addison Wesley,
Boston, Massachusetts, 1995.










[22] J. Postel. RFC 793: Transmission control protocol, September 1981.

[23] L. Kleinrock. Queueing S-it~i-- Toi- I "y, volume 1. John Wiley and Sons,
New York, 1975.

[24] J. Semke, M. Mathis, and J. Mahdavi. Automatic TCP buffer tuning.
SIGCOMM 98, pages 315-323, 1998.

[25] Brian L. Tierney, Jason Lee, Brian Crowley, Mason Holding, Jeremy Hylton,
and Fred L. Drake, Jr. A network-aware distributed storage cache for data-
intensive environments. In Proceedings of the Eighth IEEE International
S;I,,l'..-: ii on High Performance Distributed CoiiputIinh, pages 185-193,
Redondo Beach, CA, August 1999. IEEE Computer Society Press.

[26] I. Foster, J. Geisler, C. Kesselman, and S. Tuecke. Managing multiple
communication methods in high-performance networked computing systems.
Journal of Parallel and Distributed Coiuuiihfitin, 40:35-48, 1997.

[27] Message Passing Interface Forum. MPI: A message-passing interface standard.
Technical Report UT-CS-94-230, 1994.

[28] P. Tobin Maginnis. Design considerations for the transformation of MINIX
into a distributed operating system. In ACM, editor, Proceedings, focus
on software / 1988 ACM Sixteenth Annual Computer Science Conference,
February 23-25, the Westin, Peachtree Plaza, Atlanta, Georgia, pages 608-615,
New York, NY 10036, USA, 1988. ACM Press.

[29] Vivek S. Pai, Peter Druschel, and Willy Zwaenepoel. Flash: An efficient and
portable web server. In Proceedings of the 1999 USENIX Annual Technical
Conference (USENIX-99), pages 199-212, Berkeley, CA, June 6-11 1999.
USENIX Association.

[30] Yoann Padioleau and Olivier Ridoux. A logic file system. In Proceedings of
USENIX 2003 Annual Technical Conference, pages 99-112. USENIX, June
2003.

[31] Paul Avery and Ian Foster. The griphyn project: Towards petascale virtual-
data grids. Technical Report GriPhyN-2000-1, University of Florida, 2001.















BIOGRAPHICAL SKETCH

Pradeep Padala was born on August 22nd, 1979, in Srikakulam, Andhra

Pradesh, India. He received his undergraduate degree, Bachelor of Engirl. 'ii-r.

computer science and engineering, from Motilal Nehru Regional Engineering

College, Allahabad, India, in M.;- 2000.

Pradeep worked in Hughes Software Systems from August 2000 to August

2001. He joined the University of Florida in Fall 2001 to pursue his master's degree.

His research interests include distributed systems and operating systems with an

emphasis on grid computing. More details about him can be found on his web site

at http://www.cise.ufl. edu/~ppadala