Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 my master thesis (a copy on write WORM filesystem) and this source did contain tmpfs. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 -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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. 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:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
* 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* 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 d...@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@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
* 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 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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Which directories must be part of rpool?
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
