zfs discuss - Sep 2009 - Which directories must be part of rpool?

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
http://www.boostpro.com

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 root pool is not tested by us and I''ve
heard of one example recently of breakage when usr and var were moved
to a non-root RAIDZ pool.

It would be cheaper and easier to buy another disk to mirror your root
pool then it would be to take the time to figure out what could move out
and then possibly deal with an unbootable system.

Buy another disk and we''ll all sleep better.

Cindy

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.
>

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 other non-system-related
> datasets in the root pool, then feel free to move them out.
Well, for example, surely /opt can be moved?
> Moving OS components out of the root pool is not tested by us and
I''ve
> heard of one example recently of breakage when usr and var were moved
> to a non-root RAIDZ pool.
>
> It would be cheaper and easier to buy another disk to mirror your root
> pool then it would be to take the time to figure out what could move out
> and then possibly deal with an unbootable system.
>
> Buy another disk and we''ll all sleep better.
Easy for you to say.  There''s no room left in the machine for another
disk.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

* David Abrahams (dave at 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* those?
> 
> > If you have datasets like /export/home or other non-system-related
> > datasets in the root pool, then feel free to move them out.
> 
> Well, for example, surely /opt can be moved?
Don''t be so sure.
> > Moving OS components out of the root pool is not tested by us and
I''ve
> > heard of one example recently of breakage when usr and var were moved
> > to a non-root RAIDZ pool.
> >
> > It would be cheaper and easier to buy another disk to mirror your root
> > pool then it would be to take the time to figure out what could move
out
> > and then possibly deal with an unbootable system.
> >
> > Buy another disk and we''ll all sleep better.
> 
> Easy for you to say.  There''s no room left in the machine for
another disk.
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 breaks.

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 time or two during
image-updates/package installs.

On my 2010.02/123 system I see:

bin             Symlink to /usr/bin
boot/
dev/
devices/
etc/
export/         Safe to move, not tied to the ''root'' system
kernel/
lib/
media/
mnt/
net/
opt/
platform/
proc/
rmdisk/
root/           Could probably move root''s homedir
rpool/
sbin/
system/
tmp/
usr/
var/

Other than /export, everything else is considered ''part of the root
system''.  Thus part of the root pool.

Really, if you can''t add a mirror for your root pool, then make backups
of your root pool (left as an exercise to the reader) and store the
non-system specific bits (/export) on you''re raidz2 pool.

Cheers,

-- 
Glenn

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 list of datasets in a root pool should look something like this:

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                 

plus any other datasets you might have added.  Datasets you''ve added in
addition to the above (unless they are zone roots under 
rpool/ROOT/<be-name> ) can be moved to another pool.  Anything you have 
in /export or /export/ home can be moved to another pool.  Everything 
else needs to stay in the root pool.  Yes, there are contents of the 
above datasets that could be moved and  your system would still run 
(you''d have to play with mount points or symlinks to get them included 
in the Solaris name space), but such a configuration would be 
non-standard, unsupported, and probably not upgradeable.

lori

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 to stay in rpool in order for the
> system to work normally?
>
> Thanks.
>
>   
The list of datasets in a root pool should look something like this:


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                


plus any other datasets you might have added.  Datasets you''ve added in
addition to the above (unless they are zone roots under 
rpool/ROOT/<be-name> ) can be moved to another pool.  Anything you have 
in /export or /export/ home can be moved to another pool.  Everything 
else needs to stay in the root pool.  Yes, there are contents of the 
above datasets that could be moved and  your system would still run 
(you''d have to play with mount points or symlinks to get them included 
in the Solaris name space), but such a configuration would be 
non-standard, unsupported, and probably not upgradeable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090925/85369d74/attachment.html>

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
(only /var is supported) other wise LU breaks.

I have sub directories of /opt like /aop/app which does not contain
software installed via pkgadd.

I also split off /var/core and /var/crash.

Unfortunately when you need to boot -F and import the pool for
maintenance it doesn''t mount /var causing directory /var/core and
/var/crash to be created in the root file system.

The system then reboots but when you do a lucreate, or lumount it
fails due to /var/core and /var/crash existing on the / file system
causing the mount of /var to fail in the ABE.

I have found it a bit problematic to split of file systems from /
under zfs boot and still have LU work properly.

I haven''t tried putting split off file systems as apposed to
application file systems on a different pool but I believe there may
be mount ordering issues with mounting dependent file systems from
different pools where the parent file system are not part of the BE or
legacy mounts.

It is not possible to mount a vxfs file system under a non legacy zone
root file system due to ordering issues with mounting on boot (legacy
is done before automatic zfs mounts).

Perhaps u7 addressed some of there issues as I believe it is now
allowable to have zone root file system on a non root pool.

These are just my experiences and I''m sure others can give more
definitive answers.
Perhaps its easier to get some bigger disks.

Thanks

Peter

2009/9/25 David Abrahams <dave at boostpro.com>:
>
> 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 other non-system-related
>> datasets in the root pool, then feel free to move them out.
>
> Well, for example, surely /opt can be moved?
>
>> Moving OS components out of the root pool is not tested by us and
I''ve
>> heard of one example recently of breakage when usr and var were moved
>> to a non-root RAIDZ pool.
>>
>> It would be cheaper and easier to buy another disk to mirror your root
>> pool then it would be to take the time to figure out what could move
out
>> and then possibly deal with an unbootable system.
>>
>> Buy another disk and we''ll all sleep better.
>
> Easy for you to say. ?There''s no room left in the machine for
another disk.
>
> --
> Dave Abrahams
> BoostPro Computing
> http://www.boostpro.com
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>

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 time or two during
> image-updates/package installs.
I''d be very surprised (disappointed?) if /usr/local couldn''t
be
detached from the rpool. Given that in many cases it''s an NFS mount,  
I''m curious to know why it would need to be part of the rpool. If it  
is a ''dependency'' I would consider that a bug.

* David Magda (dmagda at 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 the time,
> >but it also screwed up my system a time or two during
> >image-updates/package installs.
> 
> I''d be very surprised (disappointed?) if /usr/local
couldn''t be
> detached from the rpool. Given that in many cases it''s an NFS
mount,
> I''m curious to know why it would need to be part of the rpool. If
it
> is a ''dependency'' I would consider that a bug.
It can be detached, however one issue I ran in to was packages which
installed into /usr/local caused problems when those packages were
upgraded.  Essentially what occurred was that /usr/local was created on
the root pool and upon reboot caused the filesystem service to go into
maintenance because it couldn''t mount the zfs /usr/local dataset on top
of the filled /usr/local root pool location.  I didn''t have time to
investigate into it fully.  At that point, spinning /usr/local off into
it''s own zfs dataset just didn''t seem worth the hassle.

Others mileage may vary.

-- 
Glenn

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 so starved for physical memory that
you couldn''t possibly install anything, AFAIK you can always
boot without dump and swap, so even if your data pool can''t
be mounted, you should be OK. I''ve done many a reboot and
pkg image-update with dump and swap inaccessible. Of course
with no dump, you won''t get, well, a dump, after a panic...

Having /usr/local (IIRC this doesn''t even exist in a straight
OpenSolaris install) in a shared space on your data pool is
quite useful if you have more than one machine unless you have
multiple architectures. Then it turns into the /opt problem.

Hiving off /opt does not seem to prevent booting, and having
it on a data pool doesn''t seem to prevent upgrade installs.
The big problem with putting /opt on a shared pool is when
multiple hosts have different /opts. Using legacy mounts seems
to be the only way around this. Do the gurus have a technical
explanation why putting /opt in a different pool shouldn''t work?

/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. Hopefully
a guru will step in here and explain why this is a bad idea, but
so far no problems...

A 32GB SSD is marginal for a root pool, so shrinking it as much
as possible makes a lot of sense until bigger SSDS become cost
effective (not long from now I imagine). But if you already have
a 16GB or 32GB SSD, or a dedicated boot disk <= 32GB than you
can be SOL unless you are very careful to empty /var/pkg/download,
which doesn''t seem to get emptied even if you set the magic flag.

HTH -- Frank

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 breaks.
Heh, that doesn''t sound like much fun.  I have a VM I can experiment
with, but I don''t want to do this badly enough to take that risk.
> 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 time or two during
> image-updates/package installs.
That''s hard to imagine.  My OpenSolaris installation didn''t
come with a
/usr/local directory.  How can mounting a filesystem from a non-root
pool under /usr possibly mess anything up?
> On my 2010.02/123 system I see:
>
> bin             Symlink to /usr/bin
> boot/
> dev/
> devices/
> etc/
> export/         Safe to move, not tied to the ''root''
system
Good to know.
> kernel/
> lib/
> media/
> mnt/
> net/
> opt/
> platform/
> proc/
> rmdisk/
> root/           Could probably move root''s homedir
I don''t think I''d risk it.
> rpool/
> sbin/
> system/
> tmp/
> usr/
> var/
>
> Other than /export, everything else is considered ''part of the
root
> system''.  Thus part of the root pool.
>
> Really, if you can''t add a mirror for your root pool, then make
backups
> of your root pool (left as an exercise to the reader) and store the
> non-system specific bits (/export) on you''re raidz2 pool.
Yeah, that''s my fallback.  Actually, that along with copies=2 on my
root
pool, which I might well do anyhow.  But you people are making a pretty
strong case for making the effort to figure out how to do the mirror
thing.

Thanks, all, for the feedback.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

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. Hopefully
> a guru will step in here and explain why this is a bad idea, but
> so far no problems...
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):
> /tmp: A directory made available for applications that need a place  
> to create temporary files. Applications shall be allowed to create  
> files in this directory, but shall not assume that such files are  
> preserved between invocations of the application.
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html

If a program is creating and deleting large numbers of files, and  
those files aren''t needed between reboots, then it really should be  
using /tmp.

Similar definition for Linux FWIW:

http://www.pathname.com/fhs/pub/fhs-2.3.html

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 context of this thread? IMO nuking is a good
thing - /tmp and /var/tmp get really cluttered up after a few months,
the downside of robust hardware and software :-). Not sure I really
care about recovering vi edits in the case of UPS failure...
> If a program is creating and deleting large numbers of files, and those
> files aren''t needed between reboots, then it really should be
using /tmp.
Quite. But some lazy programmer of 3rd party software decided to use
the default tmpnam() function and I don''t have access to the code :-(.

  tmpnam()
      The tmpnam() function always generates a file name using the
      path  prefix defined as P_tmpdir in the <stdio.h> header. On
      Solaris  systems,  the  default  value   for   P_tmpdir   is
      /var/tmp.
> 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
MSWindows) AFAIK there isn''t a native tmpfs, so programs that create
and
destroy large numbers of files run orders of magnitude slower there than
on Solaris - assuming the application doesn''t use /var/tmp for them
:-).
Compilers and code generators are typical of applications that do this,
though they don''t usually do synchronous i/o as said programmer appears
to have done.

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 separate
data pool in the context of being able to reboot and install new images?
I''ve been doing so for a long time now with no problems that I know of.
Just wondering what the gurus think...

Havn''t seen any definitive response regrading /opt, which IMO should
be a good candidate since the installer makes it a separate fs anyway.
/usr/local can definitely be kept on a separate pool. I wouldn''t move
/root. I keep a separate /export/home/root and have root cd to it via
a script in /root that also sets HOME, although I noticed on snv123
that logging on as root succeeded even though it couldn''t find bash
(defaulted to using sh). This may be a snv123 bug, but it is a huge
improvement on past behavior. I daresay logging on as root might
also work if root''s home directory was awol. Haven''t tried
it...

Cheers -- Frank

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
> MSWindows) AFAIK there isn''t a native tmpfs, ...
Are you sure about that? My Linux systems do.

http://lxr.linux.no/linux+v2.6.31/Documentation/filesystems/tmpfs.txt

--Toby
>
> Cheers -- Frank
>
>
>
>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

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.
>
> http://lxr.linux.no/linux+v2.6.31/Documentation/filesystems/tmpfs.txt
OK, so you can mount /dev/shm on /tmp and /var/tmp, but that''s
not the default, 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."
http://en.wikipedia.org/wiki/TMPFS, FC1 6 years ago. Solaris /tmp
has been a tmpfs since 1990...

Now back to the thread...

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 separate
> data pool in the context of being able to reboot and install new images?
> I''ve been doing so for a long time now with no problems that I
know of.
> Just wondering what the gurus think...
>
Moving /var/tmp works OK, I had a system root pool on an CF card and 
moved "busy" filesystems off to another pool.  I''m not sure
which
filesystem caused the problem, but this system was impossible to live 
upgrade.  swap and dump are volumes, so they can be anywhere (the both 
have commands to add/remove devices).
> Havn''t seen any definitive response regrading /opt, which IMO
should
> be a good candidate since the installer makes it a separate fs anyway.
Most of /opt can be relocated, but as I said, I was unable to live 
upgrade the box.  I only moved staroffice and then created filesystems 
with mountpoints in /opt before added applications that install to /opt.

See

http://www.sun.com/bigadmin/features/articles/nvm_boot.jsp

-- 
Ian.

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!

Cheers -- Frank

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 you sure about that? My Linux systems do.
>>
>> http://lxr.linux.no/linux+v2.6.31/Documentation/filesystems/tmpfs.txt
>
> OK, so you can mount /dev/shm on /tmp and /var/tmp, but that''s
> not the default,

It has long been the default in Gentoo. This system in particular was  
installed in 2004.
> 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."
> http://en.wikipedia.org/wiki/TMPFS, FC1 6 years ago. Solaris /tmp
> has been a tmpfs since 1990...
The question wasn''t "who was first".

--Toby
>
> Now back to the thread...
>
>
>

On 09/26/09 05:57 PM, Toby Thain wrote:
> It has long been the default in Gentoo. This system in particular was
> installed in 2004.
Not so with Fedora (before C11, anyway) or Red Hat 5. Nothing in FC10
is mapped to tmpfs. Now there''s another good reason to use Solaris over
Linux -- consistency across distributions (well, so far, I hope).
  
> The question wasn''t "who was first".
Right, it wasn''t. Just that 6 years is but an instant in application
development cycles. This application is more than 6 years old...
> --Toby
>
>>
>> Now back to the thread...
..... the good news is that /var/tmp and /var/run may officially
be mapped to tmpfs according to the bigadmin article. So the OP
should now have a very good feel for what is safe to move to a
data pool. This has been an interesting thread, especially relevant
in these days of SSDs just becoming affordable.

Cheers -- Frank

Toby Thain <toby at 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."
> > http://en.wikipedia.org/wiki/TMPFS, FC1 6 years ago. Solaris /tmp
> > has been a tmpfs since 1990...
>
> The question wasn''t "who was first".
BTW: Solaris has tmpfs since late 1987.

It is a de-facto standard since then as it e.g. helps to reduce compile times.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

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
times.
You bet! Provided the compiler doesn''t use /var/tmp as IIRC early
versions of gcc once did...

-- Frank

On Sep 27, 2009, at 12:05 AM, Joerg Schilling wrote:
> Toby Thain <toby at 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."
>>> http://en.wikipedia.org/wiki/TMPFS, FC1 6 years ago. Solaris /tmp
>>> has been a tmpfs since 1990...
>>
>> The question wasn''t "who was first".
>
> 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.
No rocket science needed :-)
  -- richard

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 of compilation.  This fails to work on some  
systems
            where the assembler is unable to read from a pipe; but the  
GNU
            assembler has no trouble.

That''s with GCC. Not sure if other compilers have anything similar.

Richard Elling <richard.elling at 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 -rf *)

Most Linux distros do AFAIR either not remove the content in /tmp or just call
(cd /tmp; rm *) which may leave all files or all files in sub-directories.

If people depend on this behavior, they make a mistake ;-)


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Frank Middleton <f.middleton at 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. The official release was probably Februars 1987,
but there have been betas before IIRC.
   
> > It is a de-facto standard since then as it e.g. helps to reduce
compile times.
>
> You bet! Provided the compiler doesn''t use /var/tmp as IIRC early
> versions of gcc once did...
I know that gcc ignored facts for a long time.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

On 09/27/09 11:25 AM, Joerg Schilling wrote:
> Frank Middleton<f.middleton at apogeect.com>  wrote:
>> 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. The official release was probably Februars
1987,
> but there have been betas before IIRC.
Do you have any references one could quote so that the Wikipedia
article can be corrected? The section on Solaris is rather skimpy
and could do with some work...

AFAIK this has nothing to do with ZFS. I wonder if we should
move it to another discussion. Apologies to the OP for hijacking
your thread, although I think the original question has been
answered only too thoroughly :-)

Cheers -- Frank

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.  Swap can be in a different pool. 
> 				
>
>

Frank Middleton <f.middleton at apogeect.com> wrote:
> On 09/27/09 11:25 AM, Joerg Schilling wrote:
> > Frank Middleton<f.middleton at apogeect.com>  wrote:
>
> >> 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. The official release was probably Februars
1987,
> > but there have been betas before IIRC.
>
> Do you have any references one could quote so that the Wikipedia
> article can be corrected? The section on Solaris is rather skimpy
> and could do with some work...
I am not sure whether my changes will be kept as wikipedia prefers to 
keep badly quoted wrong information before correct information supplied by 
people who have first hand information. 


Just to prove my information: I invented "fbk" (which Sun now calls
"lofi")
in summer 1988 after I received the sources for SunOS-4.0. "fbk" was
my
playground for the new vnode interface before I wrote "wofs" the
probably first
copy on write filesystem. I definitely know that tmpfs was in 4.0.




J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Joerg Schilling wrote:
> 
> Just to prove my information: I invented "fbk" (which Sun now
calls "lofi")
Sun does NOT call your fbk by the name lofi.  Lofi is a completely 
different implementation of the same concept.

-- 
Darren J Moffat

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 think so. 4.0.1 would have been the first release that
actually had it.

--chris
-- 
This message posted from opensolaris.org

Trying to move this to a new thread, although I don''t think it
has anything to do with ZFS :-)

On 09/28/09 08:54 AM, Chris Gerhard 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.
>
> Whether there was a patch that brought it back into 4.0 I don''t
> recall but I don''t think so. 4.0.1 would have been the first
release
> that actually had it.
> --chris
On 09/28/09 03:00 AM, Joerg Schilling wrote:
> I am not sure whether my changes will be kept as wikipedia prefers to
> keep badly quoted wrong information before correct information supplied by
> people who have first hand information.
They actually disallow "first hand information". Everything on
Wikipedia
is supposed to be confirmed by secondary or tertiary sources. That''s
why I
asked if there was any supporting documentation - papers, manuals,
proceedings, whatever, that describe the introduction of tmpfs before
1990. If you were to write a personal page (in Wikipedia if you like)
that describes the history of tmpfs, then you could refer to it in
the tmpfs page as a secondary source. Actually, I suppose if it was
in the source code itself, that would be pretty irrefutable!

http://en.wikipedia.org/wiki/Wikipedia:Reliable_sources

Wikipedia also has a lofi page (http://en.wikipedia.org/wiki/Lofi) that
redirects to "loop mount". It has no historical section at all...
There
is no fbk (file system) page.

Cheers -- Frank

Darren J Moffat <darrenm at opensolaris.org> wrote:
> Joerg Schilling wrote:
> > 
> > Just to prove my information: I invented "fbk" (which Sun
now calls "lofi")
>
> Sun does NOT call your fbk by the name lofi.  Lofi is a completely 
> different implementation of the same concept.
With this kind of driver the implementation coding trivial, it is the idea that
is important. So it does not matter that lofi is a reimplementation.


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Chris Gerhard <chris.gerhard at 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 my master thesis (a copy 
on write WORM filesystem) and this source did contain tmpfs.


J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

Frank Middleton <f.middleton at apogeect.com> wrote:
> On 09/28/09 03:00 AM, Joerg Schilling wrote:
>
> > I am not sure whether my changes will be kept as wikipedia prefers to
> > keep badly quoted wrong information before correct information
supplied by
> > people who have first hand information.
>
> They actually disallow "first hand information". Everything on
Wikipedia
> is supposed to be confirmed by secondary or tertiary sources.
That''s why I
This is why wikipedia is wrong in mny cases :-(
> asked if there was any supporting documentation - papers, manuals,
> proceedings, whatever, that describe the introduction of tmpfs before
> 1990. If you were to write a personal page (in Wikipedia if you like)
IIR, there was a talk about tmpfs on the Sun User Group meeting around 
december 6th in San Jose in 1987. Maybe someone finds the proceedings.

> http://en.wikipedia.org/wiki/Wikipedia:Reliable_sources
>
> Wikipedia also has a lofi page (http://en.wikipedia.org/wiki/Lofi) that
> redirects to "loop mount". It has no historical section at all...
There
> is no fbk (file system) page.
It is bad practise to advertize own projects on wikipedia.

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily