Hi John, > So what you provided shows how a client can look up the physical mappings > for an already established file. I'm more interested right now in where > the original mapping is determined. For example, some client wants to put > some new file 'foo.' This file is then split into parallel stripes which > are placed across the servers with different physical filenames which > might look something like: > 38cf8d50/bstreams/00000001/100000001.bstream > > Where in the code is this mapping originally determined? Does the client > do the lookup as you described and send the request for the actual > physical mapping or does the client request to write the logical name and > the mapping is done by the metaserver?
To create a new file you would call PVFS_(i)sys_create (src/client/sysint/sys-create.sm) with the name of the object(file, dir, symlink) and the handle of the parent directory in addition to attributes and a few other things (such as distribution information). Distribution information dictate how the file should be striped across the servers and code for this can be found in src/io/description/. Default distribution is the simple-stripe which store pieces of the file on all servers in a round-robin fashion. So the client-side create code requests a certain number of datafiles be created for a given logical file and also passes in the ranges of handles from which the metafile handle must be allocated from. This way the client can force a new file to have a particular handle if it so desires. Generally, the client simply passes in the range of handles that it knows from the config files. After the metafile is created, it calls in a datafile create for every dataserver involved in the operation and similar to the above mechanism it passes in the range of datafile handles from which it desires a handle to be allocated from. The return value of each of these operation is the actual handle number used for the create (1 metafile handle, N datafile handles) On a create request the server calls trove_dspace_create (src/io/trove/trove-dbpf/dbpf-dspace.c, src/server/create.sm) which in turn tries to allocate handles from its ledger (which is an in-memory compact representation of handles that are in use, that have been freed, that are already free etc). The initial state of the ledger is built by the server when it starts up by iterating over all the handles in the collection (trove_check_handle_ranges in src/io/trove/trove-handle-mgmt/trove-handle-mgmt.c) Hope this explains things better than my previous attempt! Thanks, Murali _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
