Hi William,
I think about shepperd because all other system limits are also implemented there. The main problem is that setrlimit does not implement a proper resource to control disk usage, FSIZE is not very useful and GE just reflects that limit.Assuming this is for local scratch space on Linux one thing I've been considering is using almost the whole disk as swap and then mounting a suitably sized tmpfs on $TMPDIR in the prolog followed by a umount in the epilog. Have to be careful to ensure it didn't cause real memory to be devoted to the VFS rather than processes though.Taking your approach has made me think of an alternative where LVM could be used in an easy way, creating a VG for scratch and configuring the LVs on demand for each job using the size requested. At the end the LV would be easily removed.To reduce the delay during filesystem creation, probably xfs could be used that is much faster to create. It is interesting to explore these options using prolog/epilog, even if the final solution for all purposes would probably be implemented inside shepperd.Inside shepherd? uggh. One of the things I like about GE is that it follows the software tools philosophy pretty closely. It does relatively little but has hooks in almost all the right places to let you add needed functionality. I suppose one advantage of shepherd or starter_method is that you could combine it with Linux namespaces to make a very private directory. When combined with tmpfs it might even auto free the space without an explicit umount.
With a additional setrlimit to control total disk usage that could be pretty straight forward.
The idea of isolating the process using Linux namespaces could be also a plus in some circumstances especially when data privacy is important for users.
<<attachment: jlopez.vcf>>
_______________________________________________ users mailing list [email protected] https://gridengine.org/mailman/listinfo/users
