There's a discussion going on over on the MVS-OE forum (which I started) about
the /tmp subdirectory. It's gone away from my original towards how to keep it
clean. So I thought I'd ask the UNIX wizards over here what the "industry
standard" is. One thing mentioned by a person boiled down to "del
> "industry standard" is. One thing mentioned by a person boiled down to
> "delete all the files in /tmp which belong > to a specific user when the last
> process which is running with that UID terminates" (rephrased by me). This
> got me
That I wonder consider as brave. There are cases where t
I've been known to drop files in /tmp for later collection - by myself or
others.
Have you considered skulker ?.
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the m
On 11/03/2011 14:23, McKown, John wrote:
There's a discussion going on over on the MVS-OE forum (which I
started) about the /tmp subdirectory. It's gone away from my original
towards how to keep it clean. So I thought I'd ask the UNIX wizards
over here what the "industry standard" is.
I don't s
Just to clarify, this was based on the OE reference - i.e Unix Systems
Services running under z/OS rather than zLinux.
Shane ...
On Sat, Mar 12th, 2011 at 1:44 AM, I wrote:
> Have you considered skulker ?.
--
For LINUX-390 subs
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On
> Behalf Of Shane G
> Sent: Friday, March 11, 2011 8:44 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: cleaning up /tmp
>
> I've been known to drop files in /tmp for later collection -
> by myself or othe
On Friday, March 11, 2011 09:43:47 am Alan Cox wrote:
> > "industry standard" is. One thing mentioned by a person boiled down to
> > "delete all the files in /tmp which belong to a specific user when the
> > last process which is running with that UID terminates" (rephrased by
> > me). This got me
Many Linux installations use "tmpfs" for /tmp. Personally, I do that
as a rule. (All rules are subject to exception, and I do that too.)
The advantage of tmpfs is that it magically cleans up every time you
reboot. You can get the same effect from explicit deletion of /tmp
contents when the syst
Mack said:
> You might also note that according to the FHS, /tmp is only supposed to be
> used by system processes. User-level processes are supposed to use /var/tmp.
> But of course, many programs violate that. Still, you might want to be
> cleaning up both directories.
Yes ... keep an eye on /
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On
> Behalf Of Philip Rowlands
> Sent: Friday, March 11, 2011 8:52 AM
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: cleaning up /tmp
>
> On 11/03/2011 14:23, McKown, John wrote:
> > There's a discussion going o
On Friday, March 11, 2011 10:15:49 am Richard Troth wrote:
> Mack said:
> > You might also note that according to the FHS, /tmp is only supposed to
> > be used by system processes. User-level processes are supposed to use
> > /var/tmp. But of course, many programs violate that. Still, you might
>
I currently have a dozen or so RHEL 5.6 zLinux running on multiple VM 6.1
(well, 5, but 6.1 RSN), on z10 processors.
The largest (disk space) is about 3TB and is currently FBA/SCSI
We're thinking of changing this to ECKD to take advantage of the SAP to do
the real IO, instead of IO being hand
A full set of benchmarks for different disk technologies with z/VM:
http://www.vm.ibm.com/perf/reports/zvm/html/520dasd.html
On Fri, Mar 11, 2011 at 12:57 PM, Donald Russell wrote:
> I currently have a dozen or so RHEL 5.6 zLinux running on multiple VM 6.1
> (well, 5, but 6.1 RSN), on z10 proces
I'd recommend you also look at using Emulated FBA devices as long as you are
considering alternatives. They are defined as EDEVs under z/VM. when you
compare the options. Know that the largest size devices is around 300 GB,
I've forgotten the exact size. It's an option to be aware of for a numb
Careful with those numbers. Some of those tests were on some pretty old
hardware. There have been z/VM SCSI performance improvements, qioassist,
and 2 rounds of FCP firmware improvements in the meantime. More up to
date info is probably there. You'll just have to click through some of
the links
On 11/03/2011 15:18, McKown, John wrote:
On a strict reading of the above, you can't rely on a /tmp file
existing "between invocations of the program", in other words when
a file isn't actively held open by a process. This would break many
many shell scripts I've read and written over the years
> On one hand using ECKD will get us some CPU cycles back due to more
> work
> being done by the SAP, but just recenly I heard that IO can be faster
> (higher throughput) with FBA/SCSI.
Not likely. The ability to drive up to 16 200MB/sec paths full on is very
valuable, as is PAV.
>
> I'm assum
>They are defined as EDEVs under z/VM. when
> you
> compare the options. Know that the largest size devices is around 300
> GB,
> I've forgotten the exact size.
300G is the largest EDEV you can boot VM itself from. Otherwise, EDEVs can be
as big as the underlying LUN.
--
If you haven¹t already RSVP¹d please do so as soon as practicable. We are
trying to get numbers for catering.
Neale
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the
On Fri, 11 Mar 2011 12:57:17 -0500 (EST), Donald Russell wrote:
>
> But, what are other people doing? My experience so far seems to be
> that the choice of SCSI or ECKD depends on the background of the
> people making the decision people with a s390 background are
> familiar with ECKD, people c
20 matches
Mail list logo
