I can think of various things that would go wrong with tmp on NFS. One of the
most obvious example would be to try and change the network configuration
while running, and needing some temporary file to manage that.\
I think the expectation is that /tmp should be accessible at all times, and
that it's local and (at least somewhat) volatile.
I tend to mount /tmp/ in RAM on all systems. Even my desktop. Not having to do
wait for a device IO queue when performing actions in /tmp/ can greatly
improve the responsiveness of the system.
If your application's /tmp/ storage requirements are such that they don't fit
in RAM, I don't think /tmp/ is the place where they should be stored.
On 07-10-15 03:37, Luke (Lucas) Starrett wrote:
Hi,
Can anybody give a brief history of time on why using an NFS drive for tmp is
necessarily a bad thing, and why we have a sanity check for it? We’re doing
this without any obvious side effects.
I’m aware of the checks added by changes like this:
patchwork.openembedded.org/patch/61107/
However, I don’t see the reasoning/background documented as to exactly what is
actually broken when putting tmp on NFS. Is it time skew, problems with
concurrent file access, something else?
Thanks,
Luke
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
