Home Forums OS X Server and Client Discussion Questions and Answers 10.4.3 breaks debian gcc on nfs mounts

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #364102
    smithsm
    Participant

    I am doing embedded development on an arm 9 board running Debian 3.
    I have the debian root nfsroot served from a PB G4 17″ with 10.4.3
    This setup worked in OS X 10.4.2. After the upgrade to 10.4.3 it no longer works. The bug is a subtle one. If I compile a file using gcc on the arm 9 and the a.out gets saved to the nfs file system (served by my PCool. The a.out file does not have execute permissions as it should.

    This makes it impossible to build anything that uses a big make file.

    The test is simple put the following in a file say foo.c
    int main(){return 0;}

    run
    gcc foo.c

    the result should be a file a.out with execute permissions.
    However in 10.4.3 it doesn’t. I think it is a timing problem or race condition problem. In unix you can’t create a file with execute permissions due to the base mask. One has to change the permissions after the file is created. Normally gcc will do this if the file compiles correctly. I believe that in 10.4.3 the file gets created alright but when gcc then tries to change the permissions it can’t because the server is caching the file creation.

    If I run gcc foo.c a second time without first deleting a.out, a.out will then have execute permissions. I believe because it doesn’t have to create the file this time so no race condition when it sets the permissions.

    Once I detected the problem it took me a while to believe it was nfs that was the culprit. However if I do the nfs mount on 10.3.9 there is no problem. If I do the same gcc on the local flash file system of the ARM 9 a.out has execute permissions. In every case the nfs parameters are identical. I run the test as root. I discovered this problem while trying to build python from src.

    Anybode have any idea how I can reconfigure 10.4.3 nfs server to behave like 10.4.2? or what changed so that I can experiment with my client configuration to compensate?

    here is the fstab entry on my linux client
    10.0.2.150:/nfs/nfsroot/ / nfs defaults,noauto 0 0

    I believe the nfs client default options are as follows

    rsize = 1024
    wsize = 1024
    timeo = 7
    retrans = 3
    acregmin = 3
    acregmax = 60
    acdirmin = 30
    acdirmax = 60
    flags = hard, nointr, noposix, cto, ac

    and my nfs server export
    nidump exports .
    /Data/nfsroot -maproot=root -network=10.0.2.0 -mask=255.255.255.0

    #364108
    smithsm
    Participant

    How do I determine if chmod is being called when running gcc?
    I don’t know how to even observe what is going on.

    #364134
    smithsm
    Participant

    I couldn’t really grok what information tcpdump gave me so I tried ethereal.

    In ethereal, when a.out ends up with execute permissions, there is a SETATTR call and Repy that enables owner execute permissions. When it doesn’t work there is not SETATTR that I can see. It occurrs about 6 packets after a.out is written. In every case it appears that a.out is written correctly. The file size is the same. I also did a dump with 10.3.9.
    Interestingly the process of gcc foo.c takes about 800 nfs packets in 10.4.3 and only about 500 in 10.3.9. The SETATTR is there in 10.3.9

    So why is the SETATTR not always occurring in 10.4.3?

    #364155
    smithsm
    Participant

    After some trial and error I was able to find a work around.
    Disabling attribute caching worked. This is done using the “noac” nfs option.

    #These two worked on tiger 10.4.3
    exec -c “console=ttyAM0,115200 ip=10.0.2.155:10.0.2.150:10.0.2.1:255.255.255.0:ts7250 nfsroot=10.0.2.150:/Data/nfsroot,noac”

    #fstab entry
    10.0.2.150:/Data/nfsroot/ / nfs noac,noauto 0 0

    Noteworthy is the fact that if I disable attribute caching and enable sync and dirsync that it doesn’t work, that is, if use noac,sync,dirsync then does not work. Seems that 10.4.3 nfs is fragile.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.

Comments are closed