TMPFS was not in the first release of 4.0. It was introduced to boost the
performance of diskless clients which no longer had the old network disk for
their root file systems and hence /tmp was now over NFS.
Whether there was a patch that brought it back into 4.0 I don't recall but I
don't
Chris Gerhard chris.gerh...@sun.com wrote:
TMPFS was not in the first release of 4.0. It was introduced to boost the
performance of diskless clients which no longer had the old network disk for
their root file systems and hence /tmp was now over NFS.
I did receive the SunOS-4.0 sources for
On 09/27/09 03:05 AM, Joerg Schilling wrote:
BTW: Solaris has tmpfs since late 1987.
Could you fix the Wikipedia article? http://en.wikipedia.org/wiki/TMPFS
it first appeared in SunOS 4.1, released in March 1990
It is a de-facto standard since then as it e.g. helps to reduce compile
On Sep 27, 2009, at 12:05 AM, Joerg Schilling wrote:
Toby Thain t...@telegraphics.com.au wrote:
at least as of RHFC10. I have files in /tmp
going back to Feb 2008 :-). Evidently, quoting Wikipedia,
tmpfs is supported by the Linux kernel from version 2.4 and up.
On Sep 27, 2009, at 10:41, Frank Middleton wrote:
You bet! Provided the compiler doesn't use /var/tmp as IIRC early
versions of gcc once did...
I find using -pipe better:
-pipe
Use pipes rather than temporary files for communication
between the
various stages
Richard Elling richard.ell...@gmail.com wrote:
BTW: Solaris has tmpfs since late 1987.
It is a de-facto standard since then as it e.g. helps to reduce
compile times.
Yep, and before that, there was just an rc script to rm everything in /
tmp.
IIRC, SunOS-3.x did call (cd /tmp; rm
Frank Middleton f.middle...@apogeect.com wrote:
On 09/27/09 03:05 AM, Joerg Schilling wrote:
BTW: Solaris has tmpfs since late 1987.
Could you fix the Wikipedia article? http://en.wikipedia.org/wiki/TMPFS
it first appeared in SunOS 4.1, released in March 1990
It appeared with SunOS-4.0.
Bill Sommerfeld wrote:
On Fri, 2009-09-25 at 14:39 -0600, Lori Alt wrote:
The list of datasets in a root pool should look something like this:
...
rpool/swap
I've had success with putting swap into other pools. I believe others
have, as well.
Yes, that's true.
On 26-Sep-09, at 9:56 AM, Frank Middleton wrote:
On 09/25/09 09:58 PM, David Magda wrote:
...
Similar definition for [/tmp] Linux FWIW:
Yes, but unless they fixed it recently (=RHFC11), Linux doesn't
actually
nuke /tmp, which seems to be mapped to disk. One side effect is
that (like
On 09/25/09 09:58 PM, David Magda wrote:
The contents of /var/tmp can be expected to survive between boots (e.g.,
/var/tmp/vi.recover); /tmp is nuked on power cycles (because it's just
memory/swap):
Yes, but does mapping it to /tmp have any issues regarding booting
or image-update in the
On 09/26/09 12:11 PM, Toby Thain wrote:
Yes, but unless they fixed it recently (=RHFC11), Linux doesn't
actually nuke /tmp, which seems to be mapped to disk. One side
effect is that (like MSWindows) AFAIK there isn't a native tmpfs,
...
Are you sure about that? My Linux systems do.
Frank Middleton wrote:
I suppose /var/tmp on zfs would never actually write these files unless
they were written synchronously. In the context of this thread, for
those of us with space constrained boot disks/ssds, is it OK to map
/var/tmp to /tmp, and /var/crash, /var/dump, and swap to a
On 09/26/09 05:25 PM, Ian Collins wrote:
Most of /opt can be relocated
There isn't much in there on a vanilla install (X86 snv111b)
# ls /opt
DTT SUNWmlib
http://www.sun.com/bigadmin/features/articles/nvm_boot.jsp
You pretty much answered the OP with this link. Thanks for
posting it!
On 26-Sep-09, at 2:55 PM, Frank Middleton wrote:
On 09/26/09 12:11 PM, Toby Thain wrote:
Yes, but unless they fixed it recently (=RHFC11), Linux doesn't
actually nuke /tmp, which seems to be mapped to disk. One side
effect is that (like MSWindows) AFAIK there isn't a native tmpfs,
...
Are
Hi,
Since I don't even have a mirror for my root pool rpool, I'd like to
move as much of my system as possible over to my raidz2 pool, tank.
Can someone tell me which parts need to stay in rpool in order for the
system to work normally?
Thanks.
--
Dave Abrahams
BoostPro Computing
Hi David,
All system-related components should remain in the root pool, such as
the components needed for booting and running the OS.
If you have datasets like /export/home or other non-system-related
datasets in the root pool, then feel free to move them out.
Moving OS components out of the
on Fri Sep 25 2009, Cindy Swearingen Cindy.Swearingen-AT-Sun.COM wrote:
Hi David,
All system-related components should remain in the root pool, such as
the components needed for booting and running the OS.
Yes, of course. But which *are* those?
If you have datasets like /export/home or
On 09/25/09 13:35, David Abrahams wrote:
Hi,
Since I don't even have a mirror for my root pool rpool, I'd like to
move as much of my system as possible over to my raidz2 pool, tank.
Can someone tell me which parts need to stay in rpool in order for the
system to work normally?
Thanks.
The
I have no idea why that last mail lost its line feeds. Trying again:
On 09/25/09 13:35, David Abrahams wrote:
Hi,
Since I don't even have a mirror for my root pool rpool, I'd like to
move as much of my system as possible over to my raidz2 pool, tank.
Can someone tell me which parts need
* David Abrahams (d...@boostpro.com) wrote:
on Fri Sep 25 2009, Cindy Swearingen Cindy.Swearingen-AT-Sun.COM wrote:
Hi David,
All system-related components should remain in the root pool, such as
the components needed for booting and running the OS.
Yes, of course. But which *are*
Hi David,
I believe /opt is an essential file system as it contains software
that is maintained by the packaging system.
In fact anywhere you install software via pkgadd probably should be in
the BE under /rpool/ROOT/bename
AFIK it should not even be split from root in the BE under zfs boot
On Sep 25, 2009, at 16:39, Glenn Lagasse wrote:
There's very little you can safely move in my experience. /export
certainly. Anything else, not really (though ymmv). I tried to
create
a seperate zfs dataset for /usr/local. That worked some of the time,
but it also screwed up my system a
* David Magda (dma...@ee.ryerson.ca) wrote:
On Sep 25, 2009, at 16:39, Glenn Lagasse wrote:
There's very little you can safely move in my experience. /export
certainly. Anything else, not really (though ymmv). I tried to
create
a seperate zfs dataset for /usr/local. That worked some of
On 09/25/09 04:44 PM, Lori Alt wrote:
rpool
rpool/ROOT
rpool/ROOT/snv_124 (or whatever version you're running)
rpool/ROOT/snv_124/var (you might not have this)
rpool/ROOT/snv_121 (or whatever other BEs you still have)
rpool/dump
rpool/export
rpool/export/home
rpool/swap
Unless you machine is
on Fri Sep 25 2009, Glenn Lagasse Glenn.Lagasse-AT-Sun.COM wrote:
The question you're asking can't easily be answered. Sun doesn't test
configs like that. If you really want to do this, you'll pretty much
have to 'try it and see what breaks'. And you get to keep both pieces
if anything
On Fri, 2009-09-25 at 14:39 -0600, Lori Alt wrote:
The list of datasets in a root pool should look something like this:
...
rpool/swap
I've had success with putting swap into other pools. I believe others
have, as well.
- Bill
On Sep 25, 2009, at 19:39, Frank Middleton wrote:
/var/tmp is a strange beast. It can get quite large, and be a
serious bottleneck if mapped to a physical disk and used by any
program that synchronously creates and deletes large numbers of
files. I have had no problems mapping /var/tmp to /tmp.
27 matches
Mail list logo
