All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Michael Fainstein <Michael.Fainstein@ecitele.com>
Cc: yocto@yoctoproject.org
Subject: Re: do_clean failure on NFS drive
Date: Wed, 24 Apr 2013 11:12:33 +0100	[thread overview]
Message-ID: <1500751.eqyz6Yl0CS@helios> (raw)
In-Reply-To: <62673661A504604B856269DAADA8BC281DE40AAC@ILPTWPVEXMB02.ecitele.com>

On Tuesday 23 April 2013 06:10:05 Michael Fainstein wrote:
> Recently I moved my working environment from local drive to NFS and since
> then do_clean task is failing all the time with error: ERROR: Error
> executing a python function in ......:
> OSError: [Errno 39] Directory not empty: '....../temp'
> 
> However, when I look at temp directory it is empty!
> 
> I put the following watcher on this directory:
> SNAP0="xx";while [ 1 ]; do SNAP=`ls -a
> tmp/work/ppce500v2-fsl-linux-gnuspe/elfutils-0.125-r4/temp/`;if [
> x"${SNAP}" != x"${SNAP0}" ];then echo "`date`";echo
> "${SNAP}";fi;SNAP0="${SNAP}";done
> 
> And got the following:
> Tue Apr 23 08:28:38 IDT 2013
> ./
> ../
> Tue Apr 23 08:28:51 IDT 2013
> ./
> ../
> log.do_clean@
> log.do_clean.572
> Tue Apr 23 08:28:51 IDT 2013
> ./
> ../
> log.do_clean.572
> run.do_clean.572
> Tue Apr 23 08:28:51 IDT 2013
> ./
> ../
> .nfs000000000210f27700000eb6
> Tue Apr 23 08:28:51 IDT 2013
> ./
> ../
> 
> 
> It looks like do_clean have a log file open when it tries to remove temp
> directory. It doesn't interfere with removing directory on local drive,
> however on NFS it does. If you remove open file on NFS, the file stays in
> the directory with .nfsXXXXXX name till it is closed and only then it is
> removed (i.e. when do_clean exits). This file triggers the exception
> "Directory not empty". Any suggestions how to solve this? Is this solved in
> latest version? I am using Freescale's SDK 1.3
> QorIQ-SDK-V1.3-20121114-yocto that is based on Yocto version 1.2.1

I have to say I don't think we support having TMPDIR on NFS, particularly 
because of cases like this where NFS does not behave in the same way as a 
standard filesystem. Aside from our own code, we'd have to take care of any 
subtle issues in the build systems of every piece of upstream software being 
built, and that's a bit too much to support.

However, if you or someone else can figure out how to fix this specific problem 
in a reasonable manner and send a patch, it would probably be accepted; but 
AFAIK we still recommend not using NFS for this.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


  reply	other threads:[~2013-04-24 10:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-23  6:10 do_clean failure on NFS drive Michael Fainstein
2013-04-24 10:12 ` Paul Eggleton [this message]
2013-04-24 12:00   ` Michael Fainstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1500751.eqyz6Yl0CS@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=Michael.Fainstein@ecitele.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.