[OmniOS-discuss] LOFS LX chdir bug with steps to reproduce
Mini Trader
miniflowtrader at gmail.com
Mon Jan 16 20:38:28 UTC 2017
That is correct I am on 151020 just moved up from LTS for this feature.
Just to be clear about one thing.
If you run this on a regular directory in the LX zone there is no issue. It
only takes place if the directory being read is from the LOFS mount of a
ZFS dataset. My mount has a property of read only. I did not try without
the readonly option.
That would be awesome if there is already a fix. This feature is pretty
amazing!
On Mon, Jan 16, 2017 at 3:24 PM Dan McDonald <danmcd at omniti.com> wrote:
> Thank you. I've discussed with Joyent, and they couldn't reproduce it.
> They have a fix we don't, so between that and whether or not it's fixed on
> bloody (you're on r151020, right mini?), I'll have to try it myself. It's
> possible the Joyent fix (outside LX, not yet upstreamed) may cure what ails
> you.
>
> FYI,
> Dan
>
> Sent from my iPhone (typos, autocorrect, and all)
>
> On Jan 16, 2017, at 1:02 PM, Mini Trader <miniflowtrader at gmail.com> wrote:
>
> 1. Does not happen on native.
> 2. My non-global zones are under /tank/zones/
> 3. It uses python - but the calls are all stdlib calls, no magic they are
> going directly to C. You can reproduce with same calls on C the system
> will eventually return ENOENT/ERRNO=2.
> 4. Looks to be LX specific. I also tested in global zone with LOFS. No
> issue.
>
> Thanks!
>
> On Mon, Jan 16, 2017 at 12:13 PM, Dan McDonald <danmcd at omniti.com> wrote:
>
> Thank you for doing this! Some questions in-line:
>
>
>
>
>
> > On Jan 16, 2017, at 10:40 AM, Mini Trader <miniflowtrader at gmail.com>
> wrote:
>
>
> >
>
>
> > I spent a bit of time yesterday using dtrace and looking at the source.
> I believe I found why the system is falsely reporting that the current
> directory does not exist and have created a simple program to reproduce the
> problem. The problem seems to be related to when v_path in the vnode
> struct goes above a certain number of characters. This will only break on
> LOFS if inside the LX zone. Every time a program performs a chdir('..')
> and up to another dir the system stored working directory is falsely
> growing.
>
>
>
>
>
> Have you tried this on a native zone (just to make sure) as well?
>
>
>
>
>
> > Here are the steps to reproduce.
>
>
> >
>
>
> > 1. Mount a ZFS dataset via LOFS for your LX zone.
>
>
> > 2. Create a directory in the dataset called test
>
>
> > 3. In the test directory create another directory called 'Chdir Test'
>
>
>
>
>
> Does it matter where (global zone, inside LX zone) these directories gets
> created?
>
>
>
>
>
> > 4. Run the program below. All this is doing is going up a directory and
> dropping down a directory. We want to fill up v_path.
>
>
>
>
>
> Python...
>
>
>
>
>
> > 5. The program will bomb before iteration 1000. Really there should be
> no limit.
>
>
> >
>
>
> > import os
>
>
> > import time
>
>
> >
>
>
> > #time.sleep(15)
>
>
> > os.chdir('/tank/bigtest/test')
>
>
> > for i in xrange(1000):
>
>
> > print i
>
>
> > os.chdir('Chdir Test')
>
>
> > os.getcwd()
>
>
> > os.chdir('..')
>
>
> >
>
>
> > I used the following dtrace to get insight into what was happening (ran
> it from global zone).
>
>
> >
>
>
> > dtrace -n 'fbt:genunix:vnodetopath_common:entry /pid == $target/ {
> printf("%s\n",stringof(args[1]->v_path)) }' -q -x strsize=4k -p 22482
>
>
> >
>
>
> > Uncomment the sleep line so that you can determine the PID when running
> dtrace.
>
>
>
>
>
> I'm forwarding this note on to Joyent, so they can see what's going on. I
> think this may be an LX bug, but I'm not sure.
>
>
>
>
>
> Thanks,
>
>
> Dan
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20170116/7df8d28c/attachment.html>
More information about the OmniOS-discuss
mailing list