locked
Drive letter mapping RRS feed

  • Question

  • I'm working with a legacy application that uses drive letters.  How are people handling drive letter mapping on their older apps without impacting other runs on the cluster?

     

    I have tried using "net use x: ...", but I'm a bit confused as to how it affects the environment.  I can do a "clusrun net use..." interactively and it will set the drive letter on the whole cluster, but this is not seen by the application when I launch a CCS run from a script.  Is the CCS run a completely isolated environment from the interactive user (even when using the same login and password)?

     

    So, I've added a task for "net use x:..." (and set dependencies appropriately), and that seems to work, but how do I guarantee that it is executed on all of the nodes?  (What if the node names are not known at the time the job template is built, or if there are a large number of nodes?)

     

    Finally, I read a message about multiline commands.  Can I just build my tasks with a command like so:

    net use x: \\server\path && myapp.exe argument1

     

    That sounds almost ideal.  Will the mapping go away automatically, or will it be persistant the next time something runs?  How about a longer multiline command:

     

    net use x: \\server\path && myapp.exe argument1 && net use x: /delete

     

    One problem I see with this version is that I need the delete to wait until the application is finished, but it will run immediately.  (Hopefully, "myapp" will wait until the first "net use" is complete.)

     

    I'm using CCS v1.  The thread about multi-line arguments said that this was broken in v2, which may be a concern for when I need to port it to the next version, but for now I only have to worry about v1.

     

    Does this sound like a good way to go?  I think the main concern is to find a way to do the drive mapping where other runs on the cluster will not be affected adversely by any drive remapping.

     

    Thanks,

    Gary

    Monday, April 14, 2008 2:53 PM

Answers

  • Hi Gary,

     

    Yes, the environment is totally seperate between the interactive user and the environment run by a job even if the same credentials are used.

     

    I recommend you avoid using drive letters for a number of reasons. The same drive letter can be saved/restored when a user logs out and then logs back on. The drive letter can be assigned a local peripheral. If the handle to the drive letter becomes invalid then the recovery is to delete and recreate the drive letter...

     

    To answer your question about whether the drive letter is restored is it depends on how the mapping was created (net use x: \\server\path  /PERSISTENT:YES).

     

    If you really need the net use then mpiexec net use x: ... would get the redirection performed on all the nodes assigned. This could be a seperate task or just part of a script.

     

    If you must use drive letters, have you considered using a script such as:

     

    net use x: \\server\path

    myapp.exe argument1

    net use x: /delete

     

    And then job submit \\server\path\runmyapp.bat

     

    -Colin

    Monday, April 14, 2008 4:53 PM

All replies

  • Hi Gary,

     

    Yes, the environment is totally seperate between the interactive user and the environment run by a job even if the same credentials are used.

     

    I recommend you avoid using drive letters for a number of reasons. The same drive letter can be saved/restored when a user logs out and then logs back on. The drive letter can be assigned a local peripheral. If the handle to the drive letter becomes invalid then the recovery is to delete and recreate the drive letter...

     

    To answer your question about whether the drive letter is restored is it depends on how the mapping was created (net use x: \\server\path  /PERSISTENT:YES).

     

    If you really need the net use then mpiexec net use x: ... would get the redirection performed on all the nodes assigned. This could be a seperate task or just part of a script.

     

    If you must use drive letters, have you considered using a script such as:

     

    net use x: \\server\path

    myapp.exe argument1

    net use x: /delete

     

    And then job submit \\server\path\runmyapp.bat

     

    -Colin

    Monday, April 14, 2008 4:53 PM
  • Thanks, Colin, that's helpful.  I can't help but have a couple of more questions, however! 

     

    If I were to use a persistent drive letter, that would work provided you were not concerned about other users having a different mapping.  I think one solution is to set up the network with a permanent mapping.  That's an option that I'll leave available -- I wouldn't do anything and not need to do any mapping.

     

    The other solution is to manage the mapping programmatically as part of the job.  If a temporary drive is created, it needs to be cleaned up as well.  I would rather that the drive letter not be persistent even between runs, in that case.  If it could even affect the following job, then I may need the /delete.  (It's not clear to me from your response if that is the case, but it sounds like it?)

     

    I did a quick test, and you are right that a batch file would work better (than the multi-command-line). My application runs completely before the following batch command executes.

     

    I like the idea of using mpiexec as tasks within the job, letting the scheduler enforce the order. 

     

    So, that gives me two good solutions.  Can you think of a reason to prefer one solution over the other?

    Monday, April 14, 2008 8:49 PM
  • The optimum is to avoid drive letter mapping and use UNCs.

     

    A job submitted by one user is not going to affect the jobs of another user.

     

    There are lots of potential problems for the user submitting ther job. Say a user has performed "net use /Persistent:yes" in a script. You run your script and it crashes during the mpi program. The next time the job runs x: will already be pointing at the server and will fail. If you handle the problem of x: already existing then you have to handle the problem where it points to a different share to the one you intended.

     

    For a typical script where it downloads a few files, does some work and then sends the results back, then using UNC can be more robust because the connection to the share can be reestablished successfully when the results need to be sent back.

     

    I think your solution will be more robust if you can either change the application to use UNCs or run the program with local files and do the data staging in your script.

     

    -Colin

    Monday, April 14, 2008 9:30 PM
  • Dear all

    I do have another problem : Is there anyway to permanently map file shares on a W2K3 server to a
    subdrive of a harddisk?

    in the following guide, it's described how to do drives, for example in C:backupdrive\ and to map phys.
    harddrives to this "subdrive". 

    http://ask-leo.com/26_drives_is_there_a_way_around_the_26_drive_limit_in_windows.html


    The problem I have is, we have to map around 100 to 150 file shares of a NAS system to one server.
    Perfect would be to have all these in one drive in this server. So that clients can map only one
    share of this server and will have access to all these cifs shares, like

    map \\server \share   and there will be then

    \share\cifs01
              \cifs02....etc

    as the 100 to 150 cifs comming directly of a fileserver running on a NAS, it can't be done as described in the
    link....

    Any help, ideas would be highy appreciated.

    br
    Tom
    Wednesday, August 20, 2008 10:52 AM