On Tue, Jul 08, 2003 at 10:44:49AM +0200, I wrote: >Greetings, > >Traditionally we have always setup our slices for the OS as follows ( with >disksuite mirrors): > >/ 512Meg - slice 0 >swap <SIZE OF REAL MEMORY> - slice 1(begins on physical sector >0) >/opt 2048Meg - slice 4 >/export/home 8192Meg - slice 5 >/usr 2048Meg - slice 6 >/var 4096Meg - slice 7 > >However recently we have encountered differing opinions about the way this >should be done. > >My personal reasons for choosing this layout is as follows: > >- /export/home should be limited without quotas. >- /var should be separate at least in case auditing runs away with >diskspace. >- rootdir should be limited so as to force future products to be installed >in /opt > >I have been told that this is (roughly) the new recommended way of setting >up slices: > >swap <2 x REAL MEMORY> - slice 1 >/ MAXSIZE-(SWAPSIZE*2) - slice 0 >/var <2 x REAL MEMORY> - slice 7 > >Practically is there an advantage to this as I am quite comfortable with >the old method? However I understand that times change but I don't want to >change unless there is a real advantage to do so. THANKS TO: Colin Bigam Crist Clark Alan Bradley Hichael Morton Jay Lessert David Foster John Elser Mike's List (?) Kevin Buterbaugh SUMMARY: Filesystem layout depends on the application being used. For example, a webserver will have a different OS FS layout compared to an Oracle database. It is assumed that no more than a single application is used per server. /var should be large enough to hold a crash dump. One of the replies I received mentioned that the crash dump will not necessarily be the size of the real memory. Running dumpadm will confirm that /var/crash is used as the savecore directory and c?t?d?s1 for the dump device, by default. The slice config that I believe should be adopted in my co for our Oracle DB servers on solaris (multiple shell users) would be *roughly* : / 3GB Slice 0-/dev/md/d0 SWAP <total physical ram> Slice 1-/dev/md/d1 /export/home 8GB Slice 5-/dev/md/d5 /opt 2GB Slice 6-/dev/md/d6 /var 8GB Slice 7-/dev/md/d7 Slice 5 will be used to hold the metadb's for SDS so no need for using another slice. SWAP will be typically 1 to 2 times the total physical DIMM sizes. /opt and /export/home will be soft partitions on Sol 8 and above. /usr/local is explicitly not used. The choice is still the sysadmin's but adopting an unrealistic layout is just bound to be more trouble than it's worth. Not to forget the unenviable reality of getting approval to implement this as well :| ------- REPLIES: On Tue, Jul 08, 2003 at 08:59:44AM -0600, Colin Bigam wrote: >Hi Sugan; > >Over the years I have moved towards fewer slices than I used to have. >The following are my recommendations: > >- swap is 1-2x real memory. You should have at least as much swap as >physical memory, so that you can do complete memory dumps in case >of a problem. However, more than that is less essential than it used >to be. If the disk is large enough though, than 2x real memory is >easy and safe. > >- /usr should never be isolated anymore, except in two cases. If you >are working with TINY disks (i.e. 1GB drives) and you have to put >/usr on a different drive than /, or if you're running a very secure >system and want to be able to mount /usr as read-only. 99.9% of the >time, I'd recommend merging / and /usr into one partition. > >- /var I keep as a separate partition on servers only--on workstations, >I don't much care if they fill up var inappropriately, and have to be >taken down. As far as size on servers, it's very dependent on what the >machine is used for. Naturally print and mail servers have large /var >partitions, whereas machines that do nothing but NFS have smaller ones. > >- /opt I'd just as soon keep in / again. If I'm going to be putting a >lot of 3rd party tools on the system, I like to plan on having a large >amount of space here, but putting it in a separate partition is more >trouble than it's worth. > >- /export/home is dependent on your situation. I almost always have >it separate because I generally have it shared out from one server, >and if that server gets trashed I can import it to another box in >very short order. However, if you only have a few users sharing a >single box, it might be easier to leave it alone, as part of /. > >As for the advantages, there are basically two: Ease of management, >and flexibility. > >Every slice you add is one more filesystem that has to be checked on >bootup after a crash, one more entry in vfstab that needs to be >correct (and updated as things change), and one more thing that can >go wrong. Fewer slices means less complexity. > >As for flexibility, consider this: > >/ 512MB >/opt 2048MB >/export/home 8192MB >/usr 2048MB > >Now if an OS upgrade requires more than 2GB in /usr or 0.5GB in /, >you have to repartition your entire disk. Similar problems occur if >you need to add a package (in /opt), or add more disk-using users. > >Now consider this: > >/ 10752MB > >You can install packages, upgrade the OS, add users, and do whatever >else you need to do all with the same shared space. Even if >/export/home is kept separate, the advantages of having one pile of >free disk space for / /usr and /opt are great. > >Finally, you might consider this. For every new install I do, part >of my 'post-install checklist' is to "ln -s /opt /usr/local". This >ensures that even packages from sunfreeware and elsewhere, which go >into /usr/local/bin, will actually be put into /opt. This is really >nice, even if /opt isn't a separate filesystem. > >Hope this helps. >Colin ------- On Tue, Jul 08, 2003 at 11:30:46AM -0700, Crist Clark wrote: >A couple observations: > >- I think your motivation for separating out the home directories, > /export/home, is good. It is a Bad Thing for mortal users to be able > to fill up /. > >- I think the /var you have is too small, depending on how big "REAL > MEMORY" is. /var should be big enough to handle: > > 1) All of the pkg and patch information above /var/sadm. This can > really add up, BTW. Although cleaning out the autogenerated > backout patches after a while can keeps this under control. > > 2) Plus all of the logs you want to retain on the system at a given > time. > > 3) Plus any scratch space or logs that 3rd party packages might want to > put in /var (many can use considerable space in /var/opt or other > locations). > > 4) All IN ADDITION TO at least one or two times REAL MEMORY to hold > some crash dumps. > >- Eliminating /usr is a Good Thing. There really is no reason to separate > the two any more (the only reason it was done historically was because > / and /usr wouldn't fit on one disk). Anyway, Solaris is almost unusable, > even for single-user mode disaster recovery, without /usr. Put /usr in > /. > >- The /opt one is the only "maybe." If the number of 3rd party packages > is static and their behavior well understood (i.e. they don't write a > lot of dynamic data to /opt), you can fold it into /. If this is one > of those systems with an ever growing /opt or one with some funky, > poorly coded and documented apps, you may want to protect / from them. > >- Finally, you have to consider how partitioning may affect backup > procedures. >-- >Crist J. Clark ------ On Tue, Jul 08, 2003 at 11:06:10AM +0200, Alan Bradley - CPX WC wrote: >Hi Sugan, > >I normally like to make swap 2 x Memory (at least) but personally I don't >see any tangible benefit for you changing the way you are doing it. If it >works fine then stick with it in my opinion. > >Regards, >Alan Bradley. ------ On Tue, Jul 08, 2003 at 11:41:56AM +0200, Peter.Ondruska@fajx.net wrote: >I don't see any positive point why "new" recommendation is based on memory >size, especially in / and /var filesystems. >Sizing / and /var should be done according to application, growth, etc. >I'd recommend / with 4GB and /var at least 4GB as well. For some systems I >survive with much less space. ------ On Tue, Jul 08, 2003 at 08:56:12AM -0500, Mike's List wrote: >To optimize performance... > >slice 0 swap size depends on memory and applications so allocate > accordingly, besides, adding swap is easy as a couple > of commands so no big deal if swap is 1024 or 512, etc. >slice 1 / rest of disk >slice 3 /var 4096 > >...done, again, it depends on what your server is doing, if it's not doing >oracle or anything intensive just keeps it the way it is. > >- Mike ------- On Tue, Jul 08, 2003 at 09:11:21AM -0500, John Elser wrote: >Susan, > >I prefer your setup, with the different file systems. I guess primarily >because if a file system fills up with a run away job, the whole system >doesn't crash. > >Security is probably tighter with different file systems. > >On systems that don't have much disk space (test severs), I've set them up >with limited number of file systems, but on systems that space is not an >issue, I'd prefer to have mount points instead of directories off of root >(/). > >John ------- On Tue, Jul 08, 2003 at 09:49:16AM -0700, Jay Lessert wrote: >On Tue, Jul 08, 2003 at 10:44:49AM +0200, Sugan Moodley wrote: >> Traditionally we have always setup our slices for the OS as follows ( with disksuite mirrors): >> / 512Meg - slice 0 >> swap <SIZE OF REAL MEMORY> - slice 1(begins on physical sector 0) >> /opt 2048Meg - slice 4 >> /export/home 8192Meg - slice 5 >> /usr 2048Meg - slice 6 >> /var 4096Meg - slice 7 > >This is probably a little more complicated than it needs to be; in >particular, there is probably no good reason for seperate / and /usr. > >> swap <2 x REAL MEMORY> - slice 1 >> / MAXSIZE-(SWAPSIZE*2) - slice 0 >> /var <2 x REAL MEMORY> - slice 7 > >IMO, if you are going to have home directories on a multiuser machine, >they should not be in /. > >My personal setup for single-disk desktop machines here is: > >/ 3GB Disk is cheap, I *never* want to be short, > actual use is about 1GB for Solaris 8. > >swap 3GB Disk is cheap, it is nice to have a big > (size limited) tmpfs /tmp around. > >/var 3GB Disk is cheap, we have applications that > can run large print/plot jobs, and I never > want to run out of room for /var/sadm. > >/local remainder wide-open local scratch space > >On my desktop boxes, there are NO home directories (that is all on a >central file server). The desktop boxes are not backed up in any >way; if we lose a disk, I slap a new one in and jumpstart. > >No production software is installed in /opt on desktop machines, that >goes in automount maps on the central file server. But / is big enough >that I *can* use /opt for non-production experiments. > >Boot disks on servers are set up much the same way, except they >actually get backed up (because of vxvm/NIS/printer/etc. >installations). > >> Practically is there an advantage to this as I am quite comfortable >> with the old method? However I understand that times change but I don't >> want to change unless there is a real advantage to do so. > >Combined /, /usr, /opt is perhaps a little more flexible because >the free space is pooled. > >I think home directories in / is a bad thing (except maybe for >home computers). > >I don't see why size of /var should have *anything* to do with >RAM. That seems silly. > >Size of swap is a very individual requirement. > >-- >Jay Lessert -------- On Tue, Jul 08, 2003 at 01:57:45PM -0500, Kevin Buterbaugh wrote: >Sugan, > > I used to set up my root disk the "old" way, too. Now I use the >"new" method, with one variation. I put /var in slice 6 and use slice 7 >for my metadb replicas. > > Why did I switch? First, it makes mirroring simpler (fewer slices). >Second, it makes it less likely that an individual filesystem will fill. >Third, the historical reason for the "old" method was based largely on the >fact that tape drives could only back up small filesystems to a single >tape. That's obviously no longer true. > > As far as sizing the slices using the new method is concerned, I look >at the amount of RAM in the system and the intended use of the system to >make my sizing determinations. For example, on a V880 with 32 GB RAM, I'm >sure not configuring anywhere near 64 GB of swap! I typically never size >swap bigger than RAM. /var is 1 - 4 GB depending on what the system is >being used for and how big my root disk is. Slice 7 for metadb replicas >is now 12 MB, since Sun upped the size in Solaris 9. Root filesystem gets >everything else. > > Of course, neither method is right or wrong. Look at the pro's and >con's of each and decide for yourself. HTH... > >================================== > >Kevin Buterbaugh - Systems Engineer ------ On Tue, Jul 08, 2003 at 06:10:11AM -0700, Hichael Morton wrote: >swap does not depend on real memory any more. > >we have machine with 8gb of ram but the swap partition is less than >that. the last core file was only 1.3gb > >for the smaller servers (e250, e450, v100, v120, netra t1 105, etc.), i >use twice the amount of ram for swap but on the bigger servers (v880), >we use smaller partitions. > >it depends on your usage. if i suspect that need for more, i create a >second partition for swap to be used in the future. since we don't >have end users, figuring swap is easier. > >if you have the luxuary of several machines or several boot drives, you >can experiment. fortunately, the tools exist to monitork ram and swap >and develope a good working model for your site. > > >hope this helps. -------- On Tue, Jul 08, 2003 at 09:47:29AM -0700, David Foster wrote: > >As disks become larger this becomes less of an issue. >My preference is for a separate /var for reasons you >state, and to avoid DoS problems with world-writable >directories. Everything else goes in /. Every time >it's been done another way we always end up having to >redistribute stuff when one or another partition fills up. > >Dave Foster -------- Sugan Moodley Unix Systems Administrator - Midrange Support 2nd Floor ABSA Towers South, 160 Main Street, Johannesburg, 2001, South Africa PO Box 7735, Johannesburg, 2000, South Africa _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Jul 8 18:09:54 2003
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:16 EST