Hi J. R. Okajima,
thank you for your prompt response.
I'm assuming from your response that in general you expect AUFS to work with
PREEMPT_RT, or is this not the case?
"Demmel Nikolaus (BOSP/PAR)":
> > we are using AUFS for our root filesystem with an tmpfs overlay and recentl=
> > y wanted to switch to a kernel with PREEMPT_RT patch. Unfortunately, it see=
> > ms that mounting aufs seems to hang about 40% of the time during boot (ther=
> > e is no specific kernel or log message). When it comes up, it seems to work=
> > correctly.
> Do you mean that mounting aufs took very long time and your system runs
> flawlessly after that?
> Interesting...
> My first suggestion to see what is going on is "strace -T -f mount -t aufs
> ..."
> which will give us a hint.
> Sometimes people sets aufs FHSM feature incorrectly. That
> setting/configuration should match in kernel-space and user-space. If it
> doesn't match, it will take a long time in mounting aufs unexpectedly.
> When FHSM is enabled both in kernel and user-space, then it will take a
> long time too. But it is an expected behaviour.
What I actually mean is that in about 40% of the time when booting into a
kernel with the RT patch, the boot hangs at
mount -t aufs -o "dirs=/rw=rw:/ro=ro" aufs $ROOT_MOUNT
in our init script and does not appear to return at all. The other 60% it works
as expected without delay.
Then exact same configuration just without PREEMPT_RT patch appears to work
100% of the time.
Does your answer still apply? Should we try the strace?
> > In order to get AUFS to compile, we needed to apply the following additiona=
> > l patch: https://github.com/beagleboard/linux/pull/108/commits/ad740435f28e=
> > 3ffb5d73a419086b0b6fd3bc7240
> Hmm, this patch reminds me a post from Daniel Vidal in May 2013 (the
> patch looks different from what I suggested, though). Refer to
> http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg04210.html
> and its thread.
Hm... interesting. To me (being unfamiliar with the innards of both PREEMPT_RT
and AUFS) this
looks like potential for a locking issue. The patch / discussion you linked
seems to suggest that
the owner should be set assigned to lock.owner, which is not done in the patch
we are using. Mind that
the patch I linked is also just something I stumbled across while googling the
initial compile error.
In particular the commit message doesn't sound too confident that the change is
actually the correct
fix and not just a way to make it compile.
Do you suggest that we should try to change it to the patch you linked?
> Next time when you post, tell me the version of patches you are using
> and the URL where I can get all of thme.
Sorry, here are the versions, I hope this helps (I'm copying this from a yocto
build config and I'm not sure in what format it would be most useful for you.
I'm not even sure what would be the best tool to use to get from the list of
repos with kernel source and patches a compiled kernel without using yocto).
https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.1.30.tar.xz
http://git.linuxfoundation.org/?p=ltsi-kernel.git;a=commit;h=079621627b2d96cf0d85a0413ce5670056a70751w
https://github.com/sfjro/aufs4-standalone.git
https://www.kernel.org/pub/linux/kernel/projects/rt/4.1/older/patches-4.1.30-rt34.tar.xz
Best,
Nikolaus
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
