Re: tmpfs race conditions

[christos%astron.com@localhost (Christos Zoulas)]

In article <20151222142704.GA3849%britannica.bec.de@localhost>,
Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
>On Mon, Oct 12, 2015 at 09:40:09PM +0200, Joerg Sonnenberger wrote:
>> I have a build machine building pkgsrc where I see some very strange
>> issues. The individual chroots share a read-only null-mounted base
>> directory with a number of tmpfs instances on top for most of the
>> writeable parts. Symptoms of the some data corruption or race
>> conditions:
>
>I've been trying to use MFS for the WRKOBJDIR a bit this week. I had one
>run that was relatively stable. During that build, I've seen the
>checksum issue and LZMA integrity errors during pkg_add. That set of
>problems is therefore not specific to tmpfs. Another issue and the
>reason why using MFS is not really an option is that it tends to dead
>lock in umount. The umount is kind of needed to keep the memory use in
>check -- discarded blocks don't result in discarded pages :(

1. Do we have a PR for the MFS umount hang?
2. Do we have a PR for the TEMPFS race?

It would be nice if we also had some synthetic tests that reproduced them...

christos