Hello all,
my original post was:
grossjoh> I have a 2 GB disk I would like to partition. I would best like to
grossjoh> use a single partition for the whole disk but people tell me
grossjoh> performance will be worse than if I split the disk in two or more
grossjoh> partitions.
grossjoh> The disk will contain mostly fairly large files: 20MB or more.
grossjoh> We have SunOS 4.1.3.
I'd like to thank the following people for answering:
tommy@boole.att.com
jdavis@cs.arizona.edu
rwolf@dretor.dciem.dnd.ca
farrell@mr.med.ge.com
mike@trdlnk.chi.il.us
kevin%kalli%ups@fourx.Aus.Sun.COM
eckhard@ts.go.dlr.de
The upshot of all of this is that I should go ahead and use one partition
though I lose some. For details see the following answers.
Thank you very much again for so much help!
.kai
-- Life is hard and then you die.----------The answers--------------------------------------------------
>>>>> On Fri, 07 May 93 15:03:01 -0400, >>>>> tommy@boole.att.com said:
tommy> I don't know about your question about performance but I thought I tommy> should mention that if most of your files will be that big, you tommy> should probably decrease the data-to-inode ratio when you do a newfs. tommy> You won't need as many inodes as usual and this will give you a bit tommy> of extra space.
>>>>> On Fri, 7 May 1993 12:58:29 MST, >>>>> "Jim Davis" <jdavis@cs.arizona.edu> said:
jdavis> In article <39305@optima.cs.arizona.edu> you write:
grossjoh> I have a 2 GB disk I would like to partition. I would best like to grossjoh> use a single partition for the whole disk but people tell me grossjoh> performance will be worse than if I split the disk in two or more grossjoh> partitions.
jdavis> I wouldn't believe them if I were you.
grossjoh> The disk will contain mostly fairly large files: 20MB or more.
jdavis> Choosing the newfs parameters carefully will probably be important, jdavis> then; read the 'maxcontig' discussion in the tunefs(8) man page. jdavis> You probably want to reduce the number of inodes too (the '-i' newfs jdavis> flag) and perhaps the free space percentage (the '-m' newfs flag).
>>>>> On Fri, 7 May 93 16:17:53 EDT, >>>>> rwolf@dretor.dciem.dnd.ca said:
rwolf> Why would multiple partitions will make performance worse? I use as few rwolf> partitions as possible /, swap, /var, /usr, /home.
>>>>> On Fri, 7 May 93 16:49:13 CDT, >>>>> farrell@mr.med.ge.com (Brian Farrell 4-6531 MRCE) said:
farrell> We don't have any 2GB disks, but here is my 2cents worth anyways. farrell> I dont' believe you can newfs a 2GB partition with out Disk Suite. farrell> Either way sine the files are so large you may want to look at farrell> tuning the filesystem w/ newfs and tunefs prior to putting data on farrell> it. The can help increate performance if you know you have only farrell> certain types of files on it.
>>>>> On Fri, 7 May 93 23:19 CDT, >>>>> mike@trdlnk.chi.il.us (Michael Sullivan) said:
mike> I see no reason why partitioning the disk will improve performance. mike> Go ahead and use one big partition.
>>>>> On Sat, 8 May 1993 16:36:00 EST, >>>>> kevin%kalli%ups@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child}) said:
kevin> One large partition can get slow if you have a highly dynamic kevin> allocation and free pattern, and you don't compact it once in a kevin> while.
kevin> If you are going to have lots of large files, I recommend setting kevin> maxbpg and maxcontig (with tunefs) to their upper limits. The first kevin> will get you more file locality on a cylinder, the second will allow kevin> larger chunks of the file to sit together.
kevin> Keep it as one, the headaches are smaller when you run out of space kevin> on one. Also make automounting it simpler.
kevin> One other comment - if you are doing your own application using these kevin> files, use mmap() wherever possible. It is *much* more efficient, and kevin> allows you to explicitly control what is in memory.
>>>>> On Mon, 10 May 93 08:48:27 +0200, >>>>> eckhard@ts.go.dlr.de (Eckhard Rueggeberg) said:
eckhard> I don't think the performance will degrade, but flexibility will eckhard> for shure.
eckhard> BTW, if you know the files will be large, then the default eckhard> parameters from newfs are not good for you. Try e.g.
eckhard> newfs -vN -c 64 -m 3 -i 8192 /dev/sdXy
eckhard> to use larger cylinder groups, a smaller root reserve, and less eckhard> inodes. -N prevents actual execution, and -v displays the mkfs eckhard> parameters newfs calls :
eckhard> ikarus:/usr/local/bin 38 # newfs -vN -c 64 -m 3 -i 8192 /dev/dsk/c0t0d0s5
eckhard> setting optimization for space with minfree less than 10%
eckhard> mkfs -N /dev/rdsk/c0t0d0s5 183040 88 20 8192 1024 64 3 90 8192 s 0 -1 8 -1
eckhard> copy the mkfs without the -N option, and replace the "s" for space eckhard> with "t" for time optimization.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:49 CDT