my knee jerk reactions (1) I don't see how tmp files spilling to shared mem can work in general since getting independent shared mem ops to provide contiguous memory is a portability issue, e.g., how do write(2) calls to a shared mem region automatically extend the region -- and how can that happen when that region fd is passed to another non-ast/ksh application
(2) even if (1) is solvable, some sftmp() callers may expect a real path name that may be passed on to other applications -- /dev/fd or some variant may be used but is it portable to do that with shared mem fds? we have already run into /dev/fd inconsistencies with socket fds (3) using statvfs() is a wormhole -- how would sftmp() know what size threshhold to request -- no matter what it uses there will be apps that exceed that threshold, or there will be multiple concurrent apps getting the green light at the same time and choking each other out it seems that if one were insistent on getting to the last bits of disk/mem space that something like a FUSE tmpfs that striped across a combination of tmp disks and shared mem would have a much better chance of actually working On Wed, 03 Apr 2013 16:31:58 +0200 Michal Hlavinka wrote: > Hi, > I've seen similar complain. What was the end of this patch? Did this > discussion continue off-list ? > Michal > On 29.10.2012 12:11, Dr. Werner Fink wrote: > > On Fri, Oct 26, 2012 at 04:42:17PM +0200, Roland Mainz wrote: > >> On Fri, Oct 26, 2012 at 3:47 PM, Dr. Werner Fink <[email protected]> wrote: > >>> I had a customer which had reported that the ksh run into problem if > >>> the /tmp partition on his system had no space left due to a process > >>> gone wild: > >>> > >>> Last login: Tue Oct 23 15:12:00 2012 from ... > >>> /etc/profile: line 12: write to 1 failed [No space left on device] > >>> /etc/profile: line 41: write to 1 failed [No space left on device] > >>> /etc/profile: line 87: write to 1 failed [No space left on device] > >>> /etc/profile: line 88: write to 1 failed [No space left on device] > >>> /etc/profile: line 91: write to 1 failed [No space left on device] > >>> /etc/profile: line 92: write to 1 failed [No space left on device] > >>> /etc/profile: line 93: write to 1 failed [No space left on device] > >>> /usr/bin/manpath: can't set the locale; make sure $LC_* and $LANG are > >>> correct > >>> /etc/profile: line 207: write to 1 failed [No space left on device] > >>> /etc/profile[324]: .: line 606: write to 4 failed [No space left on > >>> device] > >>> > >>> also the ksh93u-2012-02-29 sometimes crash in src/cmd/ksh93/sh/subshell.c > >>> which seems to be fixed in current ksh. Nevertheless IMHO the ksh should > >>> check not only if access is allowed in /tmp or /usr/tmp (which points to > >>> /var/tmp) but also if there is enough room left. If no space is left on > >>> the temporary device it would be perfect to use pipe() as fallback for > >>> stdout. > >> > >> Uhm... for which shell constructs would you like to use |pipe()| ? > > > > if ! is=$(/bin/ls -l /proc/$$/exe 2>/dev/null) ; then > > [...] > > > > tty=`tty 2> /dev/null` > > [...] > > > > test -z "$UID" && readonly UID=`id -ur 2> /dev/null` > > test -z "$EUID" && readonly EUID=`id -u 2> /dev/null` > > [...] > > > > test -z "$HOST" && HOST=`/bin/hostname -s 2> /dev/null` > > test -z "$CPU" && CPU=`/bin/uname -m 2> /dev/null` > > test -z "$HOSTNAME" && HOSTNAME=`/bin/hostname 2> /dev/null` > > [...] > > > > MANPATH="`test -x /usr/bin/manpath && /usr/bin/manpath -q`" > > [...] > > > > Btw: from src/cmd/ksh93/sh/subshell.c you can see in sh_subtmpfile() that > > if the creation of a tmp fd fails a pipe is usesd: > > > > /* popping a discipline forces a /tmp file create */ > > sfdisc(sfstdout,SF_POPDISC); > > if((fd=sffileno(sfstdout))<0) > > { > > /* unable to create the /tmp file so use a pipe */ > > [...] > > > >> > >>> See the attached patch for a suggested solution. The change in > >>> src/lib/libast/path/pathtemp.c uses statvfs() to check if the device > >>> has at least space of the sitze of one page left. The change in > >>> src/lib/libast/sfio/sftmp.c use the /dev/shm tmpfs which is used for > >>> POSIX shared memory objects. One could use shm_open()/shm_unlink() > >>> but the file descriptor then has FD_CLOEXEC set in its flags. > >> > >> A different solution (since /dev/shm is not portable) may be to probe > >> various locations for temporary files and check if there is space left > >> (e.g. /tmp (preferred because this is usually a ramdisk-like > >> filesystem on newer Unixes), /var/tmp and /usr/tmp (the traditional > >> location)) and check if at least a page (MMU default page size) is > >> available (a better algorithm may be 8*default_mmu_page_size) ... if > >> all locations do not have enough space then ksh93 should bail-out with > >> a fatal error... > > > > With glibc there exists also the functions shm_open(3) and shm_unlink(3) > > but the open for POSIX SHM will set the FD_CLOEXEC flag on the fd. Both > > shm_open(3) and shm_unlink(3) handle files relatively to /dev/shm. > > > > > > > > Werner > > > _______________________________________________ > ast-developers mailing list > [email protected] > http://lists.research.att.com/mailman/listinfo/ast-developers _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
