> It looks like from the man page of sge_types that only k, K, m, M, g and G > are accepted. Since we are just starting to see TB of RAM as a realistic > possibility in systems, perhaps a feature request should be the inclusion of > t and T in future releases?
I think so!! The type MEMORY has been associated with system memory, but in our case, we use the memory type to relate to actual disk storage on a node. I am sure other use cases exists besides ours. Depending on how ambitious I am feeling, I may dive into GE source and see if I can submit a patch file over to Son of Grid Engine. > BTW, the lower case values are based on multiples of 1000 bytes whereas the > upper case value is 1024 bytes. Ah good to know! Looks like reading man pages might be helpful for me :-) FYI: I ended up converting all files to G. Thanks Ian, -Adam -- Adam Brenner Computer Science, Undergraduate Student Donald Bren School of Information and Computer Sciences Research Computing Support Office of Information Technology http://www.oit.uci.edu/rcs/ University of California, Irvine www.ics.uci.edu/~aebrenne/ [email protected] On Mon, Apr 1, 2013 at 8:42 AM, Ian Kaufman <[email protected]> wrote: > It looks like from the man page of sge_types that only k, K, m, M, g and G > are accepted. Since we are just starting to see TB of RAM as a realistic > possibility in systems, perhaps a feature request should be the inclusion of > t and T in future releases? > > BTW, the lower case values are based on multiples of 1000 bytes whereas the > upper case value is 1024 bytes. > > Ian > > > On Sat, Mar 30, 2013 at 8:41 PM, Adam Brenner <[email protected]> wrote: >> >> Howdy GE Users, >> >> We are running GE 8.1.2. I have setup a consumable resource on our >> cluster that will monitor available local storage on each of our >> execution nodes/hosts. Our expected values can be in the range of GB >> to TB. >> >> qconf -mc entry: >> >> #name shortcut type relop requestable >> consumable default urgency >> >> #------------------------------------------------------------------------------------------ >> scratch_size scratch MEMORY <= YES YES >> 0 0 >> >> When running qconf -mattr on the specific node, we get the following >> error. >> >> [root@hpc2 scratch-cron]# sh scratch-cron.sh -r >> attribute "scratch_size" is not a memory value >> FAILED: qconf -mattr exechost complex_values scratch_size=1.6T hpc2 >> produced exit code 1 >> [root@hpc2 scratch-cron]# >> (converting 1.6T to 1638.4G works fine with the above command) >> >> Is it by design that memory values do not exceed GB? Should I convert >> everything to GB values when using qconf -mattr? >> >> Thanks, >> -Adam >> >> -- >> Adam Brenner >> Computer Science, Undergraduate Student >> Donald Bren School of Information and Computer Sciences >> >> Research Computing Support >> Office of Information Technology >> http://www.oit.uci.edu/rcs/ >> >> University of California, Irvine >> www.ics.uci.edu/~aebrenne/ >> [email protected] >> _______________________________________________ >> users mailing list >> [email protected] >> https://gridengine.org/mailman/listinfo/users > > > > > -- > Ian Kaufman > Research Systems Administrator > UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu > > _______________________________________________ > users mailing list > [email protected] > https://gridengine.org/mailman/listinfo/users > _______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
