[daip] non-atomic file creation

[Andrew Biggs]

Thanks Eric - I'll set QCREAT to True.

By the way, I came across an email from Craig Walker on the internet about
problems with UVSRT and external disks on a MacBook Pro:

http://listmgr.cv.nrao.edu/pipermail/daip/2009-August/014621.html

Last night, I seemed to be experiencing the same problem and after UVSRT
had run for several hours, I gave up, started MSORT instead and went to
bed. This morning, I used UVSRT to return from BT to TB (I've UBAVG'd in
the meantime) this time putting the external disk in BADDISK. This ran
pretty quickly, although the file is smaller.

I'm on science leave in Manchester and have brought my data over on
external disk. Is it in general a good idea to avoid external disks for
scratch files?

Cheers,

Andy

On 07/03/2013 23:58, "Eric Greisen" <egreisen at nrao.edu> wrote:

>Andrew Biggs wrote:
>> Hi. I'm encountering the following error message fairly frequently:
>> 
>> AIPS 2: ZCREA2: SPACE LOCK FILE = DA02:SPACE
>> AIPS 2: ZCREA2: STILL BUSY AFTER 30 TRIES IN 60 SECONDS
>> AIPS 2: ZCREA2: A STOPPED PROCESS MAY HAVE IT MONOPOLIZED
>> AIPS 2: ZCREA2: NOTIFY THE AIPS SYSTEM MANAGER
>> AIPS 2: ZCREA2: PERFORMING NON-ATOMIC FILE CREATION INSTEAD
>> 
>> This seems to happen because I have two AIPS running at the same time. I
>> encountered it earlier when I tried to run a second instance of DBCON
>>and
>> I just got it when I typed 'RESTART' in order to change AIPS number. Is
>> there anything I can do to stop this?
>> 
>> 
>> I suspect that this has something to do with the fact that I'm running
>> AIPS on my laptop, with one data area on the laptop's internal hard disk
>> and another on an external hard drive that is plugged in via a USB
>>cable -
>> I basically never do this. Could this be right?
>
>It is possible that file creation is taking a long time.  Many years ago
>we found out that Unix gave you only that portion of the disk space you
>asked for which you actually wrote.  So we made file creation write the
>entire new file with zeros before doing anything.  Today, with big disk
>space, one does not always have to be so cautious.  See the QCREAT
>parameter - if this is a legitimate message QCREAT may help to avoid it.
>Of course, the failed process or failed file locking issues may be what
>is happening and QCREAT is less likely to fix that sort of thing.
>
>When we create a file in an area we lock SPACE while we are doing it.
>QCREAT=1 insures that that does not last long.
>
>Cheers
>
>Eric Greisen