 |
 |
So how about /dev/shm/qserv/<qservPort> or /dev/shm/qserv/<qserv_install_dir>, or something similar that is qserv-installation-specific to avoid collisions? Jacek On 03/27/2013 10:34 PM, Wang, Daniel Liwei wrote: > I don't mind having it as a default installation rule, but performance > suffers a lot if qserv isn't allowed to use /dev/shm (or other tmpfs) so > a dev/ admin will want to patch it in production and any other > conditions where speed matters. > -Daniel > > > > -------- Original message -------- > From: Jacek Becla <[log in to unmask]> > Date: 03/27/2013 9:37 PM (GMT-08:00) > To: qserv-l <[log in to unmask]> > Subject: [QSERV-L] can we adopt a new rule? > > > Hi > > Can we adopt a new rule: a qserv installation should > never rely on directories outside of qserv install > directory. I am talking about not relying on directories > such as /dev, /tmp, /var, /log, etc... I know there > was a lot of effort to move things off /tmp, /var, > /log, but I noticed we still rely at least on /dev, > e.g., our two "production" installations on lsst-db2 > are both sharing: > > scratch_path = /dev/shm/qserv > > This is not always easy to spot, I happened to > notice because /dev/shm/qserv is owned by Douglas > and I can't write to it, so my qserv fails. > > I wonder if any bad things might happen if two > installations share scratch_path... Douglas, > you might want to fix that. > > Jacek > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the QSERV-L list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1