Re: disk partition schemes
Russell Coker <[EMAIL PROTECTED]> writes: > On Thu, 5 Jul 2001 16:50, Torbjorn Pettersson wrote: > > /boot : Sector sizes and such already discussed, you will > > discover that you need a separate boot, and then it > > will be to late. You are not talking about wasing space > > here either, it can be really small, but you will need > > it for example when you start trying out alternative > > filesystems (like reiserfs or whatever) or software > > raid or other stuff... > > You can boot off ReiserFS on RAID-1 with LILO, you should be able to boot > other file systems such as XFS or JFS too. However do you REALLY want to > try out new file systems on the root fs? > Maybe not to start with, but why limit ones options for the future? > The issue isn't wasting space, it's wasting partition numbers. Partitio > numbers above 4 on Intel are liable to change when adding or removing > partitions, this is a real PITA so you want as much as possible in the > first 4 partitions. > Yes, but if you size the main OS partitions sensibly, and either leave free space at end of disk, or set aside big partition there, there is not going to be a problem with that. > > /var:Really necessary. Log files, .debs,. If this is on root > > filesystem chances are your machine will crasch, and > > not boot up. > > Have you filed bugs against the daemons that block booting when the root > FS is full? The system should boot when all partitions are totally full. > Daemons may not be able to offer full service, and some daemons may > refuse to run, but the system should boot! > I haven't had any problems with it the last couple of years. I can't really tell if this is due to me having a separate /var, or bugs being fixed, and also it is not fully debian specific, since I set up my *nix boxen the same way. > > /tmpSame reasons as with /var. If you are using the 2.4 > > kernel you could use the shmemfs (or whatever it is > > called, same as tmpfs on SunOS.) if you allocate > > enough of swap. A lot faster. > > tmpfs on Solaris is not a lot faster. Last time I tested creation of > large numbers of small files ReiserFS was faster than tmpfs. Deletion on > tmpfs is faster though. Haven't compared tmpfs wither ReiserFS. Must do that, thanks! One other thing tmpfs/shmemfs is faster at is fsck after system crasch... ;-) (I know, bad joke...) > > I have not tested the Linux tmpfs for speed. When I tried it I couldn't > login to kde when it was mounted, so for me it seemed to be not fully > functional (and thus not worthy of testing for performance). I have not > yet determined the cause of this problem (KDE startup is very complex and > complicated). > > > / & /usrYes, also necessary. Reason behind this. Your > > machine is going to crasch. You will need as much of > > operating system as possible to salvage rest of > > system with. /var /home and other partitions with > > lots of writes to are going to be in a mess, and you > > are going to have one crash were you are not able to > > fsck these partitions, but must restore data from > > backups. Debian project working towards system > > containing enough tools on '/' to do this, but don't > > know if it is ready yet. Anyway, the smaller the > > root fs is the better. (fsck times and reduce chance of > > corruption) > > Wouldn't the chance of corruption be determined by the number of writes > to the FS not the size of the FS? As usr is essentially read-only with > the exception of /usr/src (which I make a sym-link to /var or /home) I > would not expect it to add any risk by having it in the base system. > Yes, but what I was trying to say was that the more stuff I separate from the root fs, the more writes are going to other partitions, thus minimizing risk of corruption on rootfs. And also, the more readonly data I can get away from the rootfs, the lower the risk of corruption of this readonly data will be. The only exception would be to leave stuff necessary for craschrecovery on rootfs. Regards -- ## Torbjörn Pettersson # Email [EMAIL PROTECTED] Vattugatan 5 # Web www.strul.nu/~tobbe S-111 52 Stockholm, Sweden # ##
Re: disk partition schemes
Russell Coker <[EMAIL PROTECTED]> writes: > On Thu, 5 Jul 2001 16:50, Torbjorn Pettersson wrote: > > /boot : Sector sizes and such already discussed, you will > > discover that you need a separate boot, and then it > > will be to late. You are not talking about wasing space > > here either, it can be really small, but you will need > > it for example when you start trying out alternative > > filesystems (like reiserfs or whatever) or software > > raid or other stuff... > > You can boot off ReiserFS on RAID-1 with LILO, you should be able to boot > other file systems such as XFS or JFS too. However do you REALLY want to > try out new file systems on the root fs? > Maybe not to start with, but why limit ones options for the future? > The issue isn't wasting space, it's wasting partition numbers. Partitio > numbers above 4 on Intel are liable to change when adding or removing > partitions, this is a real PITA so you want as much as possible in the > first 4 partitions. > Yes, but if you size the main OS partitions sensibly, and either leave free space at end of disk, or set aside big partition there, there is not going to be a problem with that. > > /var:Really necessary. Log files, .debs,. If this is on root > > filesystem chances are your machine will crasch, and > > not boot up. > > Have you filed bugs against the daemons that block booting when the root > FS is full? The system should boot when all partitions are totally full. > Daemons may not be able to offer full service, and some daemons may > refuse to run, but the system should boot! > I haven't had any problems with it the last couple of years. I can't really tell if this is due to me having a separate /var, or bugs being fixed, and also it is not fully debian specific, since I set up my *nix boxen the same way. > > /tmpSame reasons as with /var. If you are using the 2.4 > > kernel you could use the shmemfs (or whatever it is > > called, same as tmpfs on SunOS.) if you allocate > > enough of swap. A lot faster. > > tmpfs on Solaris is not a lot faster. Last time I tested creation of > large numbers of small files ReiserFS was faster than tmpfs. Deletion on > tmpfs is faster though. Haven't compared tmpfs wither ReiserFS. Must do that, thanks! One other thing tmpfs/shmemfs is faster at is fsck after system crasch... ;-) (I know, bad joke...) > > I have not tested the Linux tmpfs for speed. When I tried it I couldn't > login to kde when it was mounted, so for me it seemed to be not fully > functional (and thus not worthy of testing for performance). I have not > yet determined the cause of this problem (KDE startup is very complex and > complicated). > > > / & /usrYes, also necessary. Reason behind this. Your > > machine is going to crasch. You will need as much of > > operating system as possible to salvage rest of > > system with. /var /home and other partitions with > > lots of writes to are going to be in a mess, and you > > are going to have one crash were you are not able to > > fsck these partitions, but must restore data from > > backups. Debian project working towards system > > containing enough tools on '/' to do this, but don't > > know if it is ready yet. Anyway, the smaller the > > root fs is the better. (fsck times and reduce chance of > > corruption) > > Wouldn't the chance of corruption be determined by the number of writes > to the FS not the size of the FS? As usr is essentially read-only with > the exception of /usr/src (which I make a sym-link to /var or /home) I > would not expect it to add any risk by having it in the base system. > Yes, but what I was trying to say was that the more stuff I separate from the root fs, the more writes are going to other partitions, thus minimizing risk of corruption on rootfs. And also, the more readonly data I can get away from the rootfs, the lower the risk of corruption of this readonly data will be. The only exception would be to leave stuff necessary for craschrecovery on rootfs. Regards -- ## Torbjörn Pettersson # Email [EMAIL PROTECTED] Vattugatan 5 # Web www.strul.nu/~tobbe S-111 52 Stockholm, Sweden # ## -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Thu, 5 Jul 2001 16:50, Torbjorn Pettersson wrote: > /boot : Sector sizes and such already discussed, you will >discover that you need a separate boot, and then it >will be to late. You are not talking about wasing space >here either, it can be really small, but you will need >it for example when you start trying out alternative >filesystems (like reiserfs or whatever) or software >raid or other stuff... You can boot off ReiserFS on RAID-1 with LILO, you should be able to boot other file systems such as XFS or JFS too. However do you REALLY want to try out new file systems on the root fs? The issue isn't wasting space, it's wasting partition numbers. Partitio numbers above 4 on Intel are liable to change when adding or removing partitions, this is a real PITA so you want as much as possible in the first 4 partitions. > /var: Really necessary. Log files, .debs,. If this is on root >filesystem chances are your machine will crasch, and >not boot up. Have you filed bugs against the daemons that block booting when the root FS is full? The system should boot when all partitions are totally full. Daemons may not be able to offer full service, and some daemons may refuse to run, but the system should boot! > /tmp Same reasons as with /var. If you are using the 2.4 > kernel you could use the shmemfs (or whatever it is > called, same as tmpfs on SunOS.) if you allocate > enough of swap. A lot faster. tmpfs on Solaris is not a lot faster. Last time I tested creation of large numbers of small files ReiserFS was faster than tmpfs. Deletion on tmpfs is faster though. I have not tested the Linux tmpfs for speed. When I tried it I couldn't login to kde when it was mounted, so for me it seemed to be not fully functional (and thus not worthy of testing for performance). I have not yet determined the cause of this problem (KDE startup is very complex and complicated). > / & /usrYes, also necessary. Reason behind this. Your > machine is going to crasch. You will need as much of > operating system as possible to salvage rest of > system with. /var /home and other partitions with > lots of writes to are going to be in a mess, and you > are going to have one crash were you are not able to > fsck these partitions, but must restore data from > backups. Debian project working towards system > containing enough tools on '/' to do this, but don't > know if it is ready yet. Anyway, the smaller the > root fs is the better. (fsck times and reduce chance of > corruption) Wouldn't the chance of corruption be determined by the number of writes to the FS not the size of the FS? As usr is essentially read-only with the exception of /usr/src (which I make a sym-link to /var or /home) I would not expect it to add any risk by having it in the base system. Also currently the jfs FSCK program is in /usr/sbin (I have filed a bug report). This means that JFS is not suitable for /usr with the current Debian packages... Oh regarding backup. I have not heard of a large ISP that will EVER backup mail for their customers. The technical issues related to backing up 1M or more mail boxes make it extremely difficult and expensive - so AFAIK no-one bothers. It is rather amusing when a hardware upgrade goes wrong though and people start sweating about whether 1M people will complain about lost mail. ;) -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
On Thu, 5 Jul 2001 16:50, Torbjorn Pettersson wrote: > /boot : Sector sizes and such already discussed, you will >discover that you need a separate boot, and then it >will be to late. You are not talking about wasing space >here either, it can be really small, but you will need >it for example when you start trying out alternative >filesystems (like reiserfs or whatever) or software >raid or other stuff... You can boot off ReiserFS on RAID-1 with LILO, you should be able to boot other file systems such as XFS or JFS too. However do you REALLY want to try out new file systems on the root fs? The issue isn't wasting space, it's wasting partition numbers. Partitio numbers above 4 on Intel are liable to change when adding or removing partitions, this is a real PITA so you want as much as possible in the first 4 partitions. > /var: Really necessary. Log files, .debs,. If this is on root >filesystem chances are your machine will crasch, and >not boot up. Have you filed bugs against the daemons that block booting when the root FS is full? The system should boot when all partitions are totally full. Daemons may not be able to offer full service, and some daemons may refuse to run, but the system should boot! > /tmp Same reasons as with /var. If you are using the 2.4 > kernel you could use the shmemfs (or whatever it is > called, same as tmpfs on SunOS.) if you allocate > enough of swap. A lot faster. tmpfs on Solaris is not a lot faster. Last time I tested creation of large numbers of small files ReiserFS was faster than tmpfs. Deletion on tmpfs is faster though. I have not tested the Linux tmpfs for speed. When I tried it I couldn't login to kde when it was mounted, so for me it seemed to be not fully functional (and thus not worthy of testing for performance). I have not yet determined the cause of this problem (KDE startup is very complex and complicated). > / & /usrYes, also necessary. Reason behind this. Your > machine is going to crasch. You will need as much of > operating system as possible to salvage rest of > system with. /var /home and other partitions with > lots of writes to are going to be in a mess, and you > are going to have one crash were you are not able to > fsck these partitions, but must restore data from > backups. Debian project working towards system > containing enough tools on '/' to do this, but don't > know if it is ready yet. Anyway, the smaller the > root fs is the better. (fsck times and reduce chance of > corruption) Wouldn't the chance of corruption be determined by the number of writes to the FS not the size of the FS? As usr is essentially read-only with the exception of /usr/src (which I make a sym-link to /var or /home) I would not expect it to add any risk by having it in the base system. Also currently the jfs FSCK program is in /usr/sbin (I have filed a bug report). This means that JFS is not suitable for /usr with the current Debian packages... Oh regarding backup. I have not heard of a large ISP that will EVER backup mail for their customers. The technical issues related to backing up 1M or more mail boxes make it extremely difficult and expensive - so AFAIK no-one bothers. It is rather amusing when a hardware upgrade goes wrong though and people start sweating about whether 1M people will complain about lost mail. ;) -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
"Kevin J. Menard, Jr." <[EMAIL PROTECTED]> writes: > Hey guys (and gals), > > I'm redoing a machine of mine. Was a Mandrake system, but now it's going > to > be a debian one ;) > > Basically, I have 20 gigs of space to tinker with (well, there's really 40 > there, but I run a hardware RAID 10). I also have half a gig of SDRAM > (sure > this would matter with swap space). Now, I have no problem running fdisk > or > anything, but I wanted to get a feel for what people are doing for various > types of systems. > > This system would be used mostly for web-hosting, so I was figuring a > large > /home partition. Likewise only one or two kernels max, so I figured a > small /boot. And finally, and this is really where I'm looking for help, > it > will be used as an IMAP/SMTP machine. So, should I create a separate /var > partition? I'm hesitant because I don't want to a) not create a large > enough partition, or b) create too large of one and waste space. Do the > performance gains outweigh this? (I'm not terribly worried about the > redundancy with the RAID 10 and all). > > I'd really be interested in what you guys think. TIA. My suggestion would be: /boot : Sector sizes and such already discussed, you will discover that you need a separate boot, and then it will be to late. You are not talking about wasing space here either, it can be really small, but you will need it for example when you start trying out alternative filesystems (like reiserfs or whatever) or software raid or other stuff... /var:Really necessary. Log files, .debs,. If this is on root filesystem chances are your machine will crasch, and not boot up. /var/spool: Neat idea. I usually don't have one, but since your are going to do isp stuff... You'll have a lot of angry customers if you lose their email... /tmpSame reasons as with /var. If you are using the 2.4 kernel you could use the shmemfs (or whatever it is called, same as tmpfs on SunOS.) if you allocate enough of swap. A lot faster. swapYes, a lot of this... / & /usrYes, also necessary. Reason behind this. Your machine is going to crasch. You will need as much of operating system as possible to salvage rest of system with. /var /home and other partitions with lots of writes to are going to be in a mess, and you are going to have one crash were you are not able to fsck these partitions, but must restore data from backups. Debian project working towards system containing enough tools on '/' to do this, but don't know if it is ready yet. Anyway, the smaller the root fs is the better. (fsck times and reduce chance of corruption) /home In above mentioned crasch, if you are able to salvage home accounts, but not email, you are in trouble. If you are not able to salvage home accounts at all, you are out of business. Allocate a separate one and backup it regurarly... Generall idea in other words, get as much stuff of the root partition as possible, and use separate partitions for stuff that gets written to a lot, and that might fill up. (Yes, your logfiles will overflow the system. Make sure they don't stop stuff from being written to other places, like /tmp, when they do, or you will not be able to login and clean it up...) Regards -- ## Torbjörn Pettersson # Email [EMAIL PROTECTED] Vattugatan 5 # Web www.strul.nu/~tobbe S-111 52 Stockholm, Sweden # ##
Re: disk partition schemes
"Kevin J. Menard, Jr." <[EMAIL PROTECTED]> writes: > Hey guys (and gals), > > I'm redoing a machine of mine. Was a Mandrake system, but now it's going to > be a debian one ;) > > Basically, I have 20 gigs of space to tinker with (well, there's really 40 > there, but I run a hardware RAID 10). I also have half a gig of SDRAM (sure > this would matter with swap space). Now, I have no problem running fdisk or > anything, but I wanted to get a feel for what people are doing for various > types of systems. > > This system would be used mostly for web-hosting, so I was figuring a large > /home partition. Likewise only one or two kernels max, so I figured a > small /boot. And finally, and this is really where I'm looking for help, it > will be used as an IMAP/SMTP machine. So, should I create a separate /var > partition? I'm hesitant because I don't want to a) not create a large > enough partition, or b) create too large of one and waste space. Do the > performance gains outweigh this? (I'm not terribly worried about the > redundancy with the RAID 10 and all). > > I'd really be interested in what you guys think. TIA. My suggestion would be: /boot : Sector sizes and such already discussed, you will discover that you need a separate boot, and then it will be to late. You are not talking about wasing space here either, it can be really small, but you will need it for example when you start trying out alternative filesystems (like reiserfs or whatever) or software raid or other stuff... /var:Really necessary. Log files, .debs,. If this is on root filesystem chances are your machine will crasch, and not boot up. /var/spool: Neat idea. I usually don't have one, but since your are going to do isp stuff... You'll have a lot of angry customers if you lose their email... /tmpSame reasons as with /var. If you are using the 2.4 kernel you could use the shmemfs (or whatever it is called, same as tmpfs on SunOS.) if you allocate enough of swap. A lot faster. swapYes, a lot of this... / & /usrYes, also necessary. Reason behind this. Your machine is going to crasch. You will need as much of operating system as possible to salvage rest of system with. /var /home and other partitions with lots of writes to are going to be in a mess, and you are going to have one crash were you are not able to fsck these partitions, but must restore data from backups. Debian project working towards system containing enough tools on '/' to do this, but don't know if it is ready yet. Anyway, the smaller the root fs is the better. (fsck times and reduce chance of corruption) /home In above mentioned crasch, if you are able to salvage home accounts, but not email, you are in trouble. If you are not able to salvage home accounts at all, you are out of business. Allocate a separate one and backup it regurarly... Generall idea in other words, get as much stuff of the root partition as possible, and use separate partitions for stuff that gets written to a lot, and that might fill up. (Yes, your logfiles will overflow the system. Make sure they don't stop stuff from being written to other places, like /tmp, when they do, or you will not be able to login and clean it up...) Regards -- ## Torbjörn Pettersson # Email [EMAIL PROTECTED] Vattugatan 5 # Web www.strul.nu/~tobbe S-111 52 Stockholm, Sweden # ## -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Wed, 4 Jul 2001 00:26, Christian Hammers wrote: > > If your root file system is at the start then it is unlikely to be > > large enough to break any boot loaders. Recent boot loaders are very > > capable... > > fill it up to more than 512MB (was it that number?) and then compile a > new kernel years later and it will be after that magical border ans > thus unaccessable. All recent versions of LILO support >1024 cylinders and >512M. They should work with >8G but I haven't tested it. I've got a machine with the first 2G of disk taken by Windows and LILO works fine with /boot on starting 2G into the disk. > > > * /var, as used for logs, can fill up completely if a program > > > get mad and prevent other programs than just syslogd from working > > > if it's on / > > > > chgrp log /var/log/*log > > Set quota for log group. Problem solved? > > I would assume that disc quota increase the load on a server. As we're > talking about a heavily loaded server wich much disc IO (else this > partitioning is not necessary) this would slowdown it, or not? When a file owned by the user/group in question is open the quota entry will remain in memory, so it will only involve a few CPU cycles for block allocation. If disk IO is the bottleneck then quotas won't slow things down noticably. There will be some extra writes for updating the quotas but that won't have a significant impact. I may have to do some benchmarks of this... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
On Wed, 4 Jul 2001 00:26, Christian Hammers wrote: > > If your root file system is at the start then it is unlikely to be > > large enough to break any boot loaders. Recent boot loaders are very > > capable... > > fill it up to more than 512MB (was it that number?) and then compile a > new kernel years later and it will be after that magical border ans > thus unaccessable. All recent versions of LILO support >1024 cylinders and >512M. They should work with >8G but I haven't tested it. I've got a machine with the first 2G of disk taken by Windows and LILO works fine with /boot on starting 2G into the disk. > > > * /var, as used for logs, can fill up completely if a program > > > get mad and prevent other programs than just syslogd from working > > > if it's on / > > > > chgrp log /var/log/*log > > Set quota for log group. Problem solved? > > I would assume that disc quota increase the load on a server. As we're > talking about a heavily loaded server wich much disc IO (else this > partitioning is not necessary) this would slowdown it, or not? When a file owned by the user/group in question is open the quota entry will remain in memory, so it will only involve a few CPU cycles for block allocation. If disk IO is the bottleneck then quotas won't slow things down noticably. There will be some extra writes for updating the quotas but that won't have a significant impact. I may have to do some benchmarks of this... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Wed, Jul 04, 2001 at 12:26:46AM +0200, Christian Hammers wrote: > I use 2.4.6-pre7 and use LVM,reiserfs and ext3 without problems. > (maybe my kernel is just too recent...) > ext3 has just recently been ported over to kernel 2.4, and you have no problems you say? (when I say recent, I mean the task began about 4 weeks ago). From what I've heard It does run. but there are still many problems. -- Nick Jennings
Re: disk partition schemes
On Mon, Jul 02, 2001 at 03:12:31PM +0200, Russell Coker wrote: > If your root file system is at the start then it is unlikely to be large > enough to break any boot loaders. Recent boot loaders are very capable... fill it up to more than 512MB (was it that number?) and then compile a new kernel years later and it will be after that magical border ans thus unaccessable. > > * /var, as used for logs, can fill up completely if a program > > get mad and prevent other programs than just syslogd from working if > > it's on / > chgrp log /var/log/*log > Set quota for log group. Problem solved? I would assume that disc quota increase the load on a server. As we're talking about a heavily loaded server wich much disc IO (else this partitioning is not necessary) this would slowdown it, or not? > >From what I've seen LVM is much better at breaking data into pieces than > it is at putting them back together... I wanted to take over maintenance > of the LVM packages for Debian but couldn't because I couldn't get it > working with a recent kernel! I use 2.4.6-pre7 and use LVM,reiserfs and ext3 without problems. (maybe my kernel is just too recent...) bye, -christian- -- Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds
Re: disk partition schemes
On Wed, Jul 04, 2001 at 12:26:46AM +0200, Christian Hammers wrote: > I use 2.4.6-pre7 and use LVM,reiserfs and ext3 without problems. > (maybe my kernel is just too recent...) > ext3 has just recently been ported over to kernel 2.4, and you have no problems you say? (when I say recent, I mean the task began about 4 weeks ago). From what I've heard It does run. but there are still many problems. -- Nick Jennings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Mon, Jul 02, 2001 at 03:12:31PM +0200, Russell Coker wrote: > If your root file system is at the start then it is unlikely to be large > enough to break any boot loaders. Recent boot loaders are very capable... fill it up to more than 512MB (was it that number?) and then compile a new kernel years later and it will be after that magical border ans thus unaccessable. > > * /var, as used for logs, can fill up completely if a program > > get mad and prevent other programs than just syslogd from working if > > it's on / > chgrp log /var/log/*log > Set quota for log group. Problem solved? I would assume that disc quota increase the load on a server. As we're talking about a heavily loaded server wich much disc IO (else this partitioning is not necessary) this would slowdown it, or not? > >From what I've seen LVM is much better at breaking data into pieces than > it is at putting them back together... I wanted to take over maintenance > of the LVM packages for Debian but couldn't because I couldn't get it > working with a recent kernel! I use 2.4.6-pre7 and use LVM,reiserfs and ext3 without problems. (maybe my kernel is just too recent...) bye, -christian- -- Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Saturday 30 June 2001 17:49, Christian Hammers wrote: > On Fri, Jun 15, 2001 at 10:13:33AM -0400, Kevin J. Menard, Jr. wrote: > > Basically, I have 20 gigs of space to tinker with (well, there's > > really 40 there, but I run a hardware RAID 10). I also have half a > > gig of SDRAM (sure this would matter with swap space). Now, I have > > no problem running fdisk or anything, but I wanted to get a feel for > > what people are doing for various types of systems. > > Seperated partitions are usefull for the following reasons for me: > * /boot because old bootloaders (and new?) have problems with bzImage > files over a certan sector number, i.e. it should be at the start of > your HDD. If your root file system is at the start then it is unlikely to be large enough to break any boot loaders. Recent boot loaders are very capable... > * /var, as used for logs, can fill up completely if a program > get mad and prevent other programs than just syslogd from working if > it's on / chgrp log /var/log/*log Set quota for log group. Problem solved? > Something I would suggest you, too is LVM. There you can partition your > harddisc(s) in arbitrary pieces (physical extends), put them together > in a big heap (volume group) and from this heap you can cut out your > virtual discs (logical volumes) and resize them as needed no matter if > they are physically in a line or scattered over all harddiscs. > Of course this requires a filesystem that can adjust, too, only > extending the (virtual) partition alone doesn't help. But reiserfs > (AFAIK) and ext2/ext3 can do it. > (well but keep in mind that this is not 10-year-approved technology so > maybe not use it with your best paying customer..) From what I've seen LVM is much better at breaking data into pieces than it is at putting them back together... I wanted to take over maintenance of the LVM packages for Debian but couldn't because I couldn't get it working with a recent kernel! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
On Saturday 30 June 2001 17:49, Christian Hammers wrote: > On Fri, Jun 15, 2001 at 10:13:33AM -0400, Kevin J. Menard, Jr. wrote: > > Basically, I have 20 gigs of space to tinker with (well, there's > > really 40 there, but I run a hardware RAID 10). I also have half a > > gig of SDRAM (sure this would matter with swap space). Now, I have > > no problem running fdisk or anything, but I wanted to get a feel for > > what people are doing for various types of systems. > > Seperated partitions are usefull for the following reasons for me: > * /boot because old bootloaders (and new?) have problems with bzImage > files over a certan sector number, i.e. it should be at the start of > your HDD. If your root file system is at the start then it is unlikely to be large enough to break any boot loaders. Recent boot loaders are very capable... > * /var, as used for logs, can fill up completely if a program > get mad and prevent other programs than just syslogd from working if > it's on / chgrp log /var/log/*log Set quota for log group. Problem solved? > Something I would suggest you, too is LVM. There you can partition your > harddisc(s) in arbitrary pieces (physical extends), put them together > in a big heap (volume group) and from this heap you can cut out your > virtual discs (logical volumes) and resize them as needed no matter if > they are physically in a line or scattered over all harddiscs. > Of course this requires a filesystem that can adjust, too, only > extending the (virtual) partition alone doesn't help. But reiserfs > (AFAIK) and ext2/ext3 can do it. > (well but keep in mind that this is not 10-year-approved technology so > maybe not use it with your best paying customer..) From what I've seen LVM is much better at breaking data into pieces than it is at putting them back together... I wanted to take over maintenance of the LVM packages for Debian but couldn't because I couldn't get it working with a recent kernel! -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Fri, Jun 15, 2001 at 10:13:33AM -0400, Kevin J. Menard, Jr. wrote: > Basically, I have 20 gigs of space to tinker with (well, there's really 40 > there, but I run a hardware RAID 10). I also have half a gig of SDRAM > (sure > this would matter with swap space). Now, I have no problem running fdisk > or > anything, but I wanted to get a feel for what people are doing for various > types of systems. Seperated partitions are usefull for the following reasons for me: * /boot because old bootloaders (and new?) have problems with bzImage files over a certan sector number, i.e. it should be at the start of your HDD. * /var, as used for logs, can fill up completely if a program get mad and prevent other programs than just syslogd from working if it's on / * /usr/local, /home etc can be on seperate partitions if your / is e.g. a standard system that's just copied from a CD image when installing a server or if you like to backup the partitions in differnet intervals. * generally as filesystems sometimes get corrupt it's good if at least some severs work. and you have a platform from which you can do a fsck (ever tried to fsck a root reiserfs? it cannot be done even if mounted only readonly (at least back somewhen)). Something I would suggest you, too is LVM. There you can partition your harddisc(s) in arbitrary pieces (physical extends), put them together in a big heap (volume group) and from this heap you can cut out your virtual discs (logical volumes) and resize them as needed no matter if they are physically in a line or scattered over all harddiscs. Of course this requires a filesystem that can adjust, too, only extending the (virtual) partition alone doesn't help. But reiserfs (AFAIK) and ext2/ext3 can do it. (well but keep in mind that this is not 10-year-approved technology so maybe not use it with your best paying customer..) bye, -christian- -- "Caution: Cape does not enable user to fly." (Batman Costume warning label)
Re: disk partition schemes
On Fri, Jun 15, 2001 at 10:13:33AM -0400, Kevin J. Menard, Jr. wrote: > Basically, I have 20 gigs of space to tinker with (well, there's really 40 > there, but I run a hardware RAID 10). I also have half a gig of SDRAM (sure > this would matter with swap space). Now, I have no problem running fdisk or > anything, but I wanted to get a feel for what people are doing for various > types of systems. Seperated partitions are usefull for the following reasons for me: * /boot because old bootloaders (and new?) have problems with bzImage files over a certan sector number, i.e. it should be at the start of your HDD. * /var, as used for logs, can fill up completely if a program get mad and prevent other programs than just syslogd from working if it's on / * /usr/local, /home etc can be on seperate partitions if your / is e.g. a standard system that's just copied from a CD image when installing a server or if you like to backup the partitions in differnet intervals. * generally as filesystems sometimes get corrupt it's good if at least some severs work. and you have a platform from which you can do a fsck (ever tried to fsck a root reiserfs? it cannot be done even if mounted only readonly (at least back somewhen)). Something I would suggest you, too is LVM. There you can partition your harddisc(s) in arbitrary pieces (physical extends), put them together in a big heap (volume group) and from this heap you can cut out your virtual discs (logical volumes) and resize them as needed no matter if they are physically in a line or scattered over all harddiscs. Of course this requires a filesystem that can adjust, too, only extending the (virtual) partition alone doesn't help. But reiserfs (AFAIK) and ext2/ext3 can do it. (well but keep in mind that this is not 10-year-approved technology so maybe not use it with your best paying customer..) bye, -christian- -- "Caution: Cape does not enable user to fly." (Batman Costume warning label) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
Hello! Just to throw a word in too. Every than and now I have been longing for a small partition with a minimal system, just with what the Debian Installation Disquette contains (~ 2 M). When fsck finds a somewhat bigger problem (my clients and friends seem like to pull the plug or press that forbidden power switch) init gives you a Single User maintainance shell, but you cannot fsck / as it is mounted. With this rescue partition you could mount that partition (should NOT be mounted otherways) fsck the whole rest of your disks and partitions without carrying rescue/root disks around Best Regards, Jorge-Le'on
Re: disk partition schemes
Hello! Just to throw a word in too. Every than and now I have been longing for a small partition with a minimal system, just with what the Debian Installation Disquette contains (~ 2 M). When fsck finds a somewhat bigger problem (my clients and friends seem like to pull the plug or press that forbidden power switch) init gives you a Single User maintainance shell, but you cannot fsck / as it is mounted. With this rescue partition you could mount that partition (should NOT be mounted otherways) fsck the whole rest of your disks and partitions without carrying rescue/root disks around Best Regards, Jorge-Le'on -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Saturday 23 June 2001 21:13, Nick Jennings wrote: > > However if you have a single large partition then when you are > > writing data the FS drivers can optimise things. > > I always thought that this was a performance hit, I know I've read it > in places before, but I can't seem to find them as I look right now. If you are using an older kernel (say 2.0 series) on an SMP machine then this could be true. Older kernels didn't manage SMP very effectively and often locked other CPUs out of resources. Having two separate file systems might in some situations allow access to cached data where otherwise there would be spinlocks to deal with. I think that 2.4.x has solved most of these issus (and 2.2.x was much better than 2.0.x). > > Swap is often the most used partition. Root is probably the least. > > /tmp and /home are both candidates for the most used partition. > > Having things separate like this means that in many common usage > > situations you'll have the heads seeking across the entire disk all > > the time. Having a single partition could increase performance... > > Good point, I've put / at the beginning just out of habit, put I think Same here. But 1-2 G at the start being reserved for a low utilization partition such as root doesn't matter much on a modern 40G+ drive IMHO. > that, especially on a server, /var is much more used than home is. and > /usr is where every application is executed from, that's gotta count > for something. I would venture to say that, on a server thats not > offering lots of shell accounts, /home is the least used. If the server is an IMAP server then home can still be most used. But really trying to make generalisations about what a "server" does isn't a good idea. There's too many types of servers. > > If sticking another disk in is so easy then why not just install lots > > of disks in a RAID array from the start? That'll get the best > > performance... > > Well because a hardware RAID is more expensive than a scsi or ide > drive. Also because I'm thinking of one disk, with the possible > expansion onto another one, or two. not starting out with several. Software RAID is cheap and easy... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
On Sat, Jun 23, 2001 at 10:19:31AM +0200, Russell Coker wrote: > On Friday 22 June 2001 17:46, Duane Powers wrote: > > on /. I _always_ use a seprarate /home, so I can keep data in case I > > have to reinstall the OS, (successful intrustion attempt, etc.) and > > Of course the re-installation could start with: > rm -rf /etc /sbin /bin /var /usr /boot /lib > Well, generally if you're doing an install and have a partition you don't wan't the installer to mess with, not specifiying it as /home and just let it do the install with home on the / partition will ensure taht your data isn't damaged. Then afterward just edit the fstab and remount /home onto your old home partition. -- Nick Jennings
Re: disk partition schemes
On Sat, Jun 23, 2001 at 09:34:59AM +0200, Russell Coker wrote: > On Saturday 23 June 2001 04:10, Nick Jennings wrote: > > > > The main performance benefit to having directories reside on their own > > partition relates to file write/read access. It's very important to > > have var on it's own seperate partition, specifically because it's > > probably the most actively written to directory. > > OK. If you have a single physical hard drive or RAID array, the how will > having /var on a separate partition give any benefit? Disk access still > goes to the same hardware and is still limited by head seek times and > rotational delays of the hardware. Having two seeks on the same > partition or two seeks on separate partitions should not perform any > differently. I guess I was going by the same logic of the swap partition, having your partitions ordered by most usage. I also added into this having your system partitioned into logical segments to increase maintnence ease. > > However if you have a single large partition then when you are writing > data the FS drivers can optimise things. I always thought that this was a performance hit, I know I've read it in places before, but I can't seem to find them as I look right now. > > > Another little performance gain is the order in which you partition > > your disks (the closer to the 0'th cylinder the faster the access time. > > This depends on the type of device. This is a general rule that doesn't > always apply. But when it does apply it's not so small. 50% extra > performance at the start of the disk is not uncommon. > > AFAIK I'm the only person to publish a benchmark program to measure > this... > > > For instance, this is the order in which I usually go about > > partitioning my drive (note: it varies depending on it i'm setting up a > > workstation or a server, but they are similar). > > > >size: totalmem*2 (64mb = 128mb partition) > > / > > /tmp > > > > /usr > > /var > > /home > > Swap is often the most used partition. Root is probably the least. /tmp > and /home are both candidates for the most used partition. Having things > separate like this means that in many common usage situations you'll have > the heads seeking across the entire disk all the time. Having a single > partition could increase performance... Good point, I've put / at the beginning just out of habit, put I think that, especially on a server, /var is much more used than home is. and /usr is where every application is executed from, that's gotta count for something. I would venture to say that, on a server thats not offering lots of shell accounts, /home is the least used. > > > If I run out of room on /var/www or /var/cvs or something, I can stick > > another disk in and mount that in its place instead. I used to get > > worried about wasted space, but if you just over estimate a bit, you > > should be fine with most of the partitions that don't grow (like /, > > /tmp, /usr). And you just give the most space the the ones that can > > grow. Now I find a nice partitioning scheme to be much more manageable > > and the performance is very noticable. > > If sticking another disk in is so easy then why not just install lots of > disks in a RAID array from the start? That'll get the best performance... > Well because a hardware RAID is more expensive than a scsi or ide drive. Also because I'm thinking of one disk, with the possible expansion onto another one, or two. not starting out with several. -- Nick Jennings
Re: disk partition schemes
On Friday 22 June 2001 17:46, Duane Powers wrote: > Hm, This is interesting, I have almost always used separate partitions, > such as /var, and it's saved my butt a couple times. If a log file > starts to run away, which I've had happen a twice, it can't overflow > the boundaries of the partition and crash the box, which it can if it's Of course you could always setup quotas to limit the storage space for logs. If you have a log directory such as /var/log/apache created SGID and then apply a quota for that group then it'll limit log creation... > on /. I _always_ use a seprarate /home, so I can keep data in case I > have to reinstall the OS, (successful intrustion attempt, etc.) and Of course the re-installation could start with: rm -rf /etc /sbin /bin /var /usr /boot /lib Also if your machine has been cracked then you have to check for SUID programs on /home... > I've been using a /boot for no good reason. :o) The other benefit > could, I've theorized, come from chrooting certain processes, If you > leave them on a separate partition, and somehow someone exploits the > partition, you can restore from your backup of the partition, without > _too_ much difficulty. Unless your backup mathod is "cat /dev/hda1 > /dev/rmt" it's just as easy to restore a sub-directory as to restore a file system. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
On Saturday 23 June 2001 21:13, Nick Jennings wrote: > > However if you have a single large partition then when you are > > writing data the FS drivers can optimise things. > > I always thought that this was a performance hit, I know I've read it > in places before, but I can't seem to find them as I look right now. If you are using an older kernel (say 2.0 series) on an SMP machine then this could be true. Older kernels didn't manage SMP very effectively and often locked other CPUs out of resources. Having two separate file systems might in some situations allow access to cached data where otherwise there would be spinlocks to deal with. I think that 2.4.x has solved most of these issus (and 2.2.x was much better than 2.0.x). > > Swap is often the most used partition. Root is probably the least. > > /tmp and /home are both candidates for the most used partition. > > Having things separate like this means that in many common usage > > situations you'll have the heads seeking across the entire disk all > > the time. Having a single partition could increase performance... > > Good point, I've put / at the beginning just out of habit, put I think Same here. But 1-2 G at the start being reserved for a low utilization partition such as root doesn't matter much on a modern 40G+ drive IMHO. > that, especially on a server, /var is much more used than home is. and > /usr is where every application is executed from, that's gotta count > for something. I would venture to say that, on a server thats not > offering lots of shell accounts, /home is the least used. If the server is an IMAP server then home can still be most used. But really trying to make generalisations about what a "server" does isn't a good idea. There's too many types of servers. > > If sticking another disk in is so easy then why not just install lots > > of disks in a RAID array from the start? That'll get the best > > performance... > > Well because a hardware RAID is more expensive than a scsi or ide > drive. Also because I'm thinking of one disk, with the possible > expansion onto another one, or two. not starting out with several. Software RAID is cheap and easy... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Sat, Jun 23, 2001 at 10:19:31AM +0200, Russell Coker wrote: > On Friday 22 June 2001 17:46, Duane Powers wrote: > > on /. I _always_ use a seprarate /home, so I can keep data in case I > > have to reinstall the OS, (successful intrustion attempt, etc.) and > > Of course the re-installation could start with: > rm -rf /etc /sbin /bin /var /usr /boot /lib > Well, generally if you're doing an install and have a partition you don't wan't the installer to mess with, not specifiying it as /home and just let it do the install with home on the / partition will ensure taht your data isn't damaged. Then afterward just edit the fstab and remount /home onto your old home partition. -- Nick Jennings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Sat, Jun 23, 2001 at 09:34:59AM +0200, Russell Coker wrote: > On Saturday 23 June 2001 04:10, Nick Jennings wrote: > > > > The main performance benefit to having directories reside on their own > > partition relates to file write/read access. It's very important to > > have var on it's own seperate partition, specifically because it's > > probably the most actively written to directory. > > OK. If you have a single physical hard drive or RAID array, the how will > having /var on a separate partition give any benefit? Disk access still > goes to the same hardware and is still limited by head seek times and > rotational delays of the hardware. Having two seeks on the same > partition or two seeks on separate partitions should not perform any > differently. I guess I was going by the same logic of the swap partition, having your partitions ordered by most usage. I also added into this having your system partitioned into logical segments to increase maintnence ease. > > However if you have a single large partition then when you are writing > data the FS drivers can optimise things. I always thought that this was a performance hit, I know I've read it in places before, but I can't seem to find them as I look right now. > > > Another little performance gain is the order in which you partition > > your disks (the closer to the 0'th cylinder the faster the access time. > > This depends on the type of device. This is a general rule that doesn't > always apply. But when it does apply it's not so small. 50% extra > performance at the start of the disk is not uncommon. > > AFAIK I'm the only person to publish a benchmark program to measure > this... > > > For instance, this is the order in which I usually go about > > partitioning my drive (note: it varies depending on it i'm setting up a > > workstation or a server, but they are similar). > > > >size: totalmem*2 (64mb = 128mb partition) > > / > > /tmp > > > > /usr > > /var > > /home > > Swap is often the most used partition. Root is probably the least. /tmp > and /home are both candidates for the most used partition. Having things > separate like this means that in many common usage situations you'll have > the heads seeking across the entire disk all the time. Having a single > partition could increase performance... Good point, I've put / at the beginning just out of habit, put I think that, especially on a server, /var is much more used than home is. and /usr is where every application is executed from, that's gotta count for something. I would venture to say that, on a server thats not offering lots of shell accounts, /home is the least used. > > > If I run out of room on /var/www or /var/cvs or something, I can stick > > another disk in and mount that in its place instead. I used to get > > worried about wasted space, but if you just over estimate a bit, you > > should be fine with most of the partitions that don't grow (like /, > > /tmp, /usr). And you just give the most space the the ones that can > > grow. Now I find a nice partitioning scheme to be much more manageable > > and the performance is very noticable. > > If sticking another disk in is so easy then why not just install lots of > disks in a RAID array from the start? That'll get the best performance... > Well because a hardware RAID is more expensive than a scsi or ide drive. Also because I'm thinking of one disk, with the possible expansion onto another one, or two. not starting out with several. -- Nick Jennings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Friday 22 June 2001 17:46, Duane Powers wrote: > Hm, This is interesting, I have almost always used separate partitions, > such as /var, and it's saved my butt a couple times. If a log file > starts to run away, which I've had happen a twice, it can't overflow > the boundaries of the partition and crash the box, which it can if it's Of course you could always setup quotas to limit the storage space for logs. If you have a log directory such as /var/log/apache created SGID and then apply a quota for that group then it'll limit log creation... > on /. I _always_ use a seprarate /home, so I can keep data in case I > have to reinstall the OS, (successful intrustion attempt, etc.) and Of course the re-installation could start with: rm -rf /etc /sbin /bin /var /usr /boot /lib Also if your machine has been cracked then you have to check for SUID programs on /home... > I've been using a /boot for no good reason. :o) The other benefit > could, I've theorized, come from chrooting certain processes, If you > leave them on a separate partition, and somehow someone exploits the > partition, you can restore from your backup of the partition, without > _too_ much difficulty. Unless your backup mathod is "cat /dev/hda1 > /dev/rmt" it's just as easy to restore a sub-directory as to restore a file system. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Saturday 23 June 2001 04:10, Nick Jennings wrote: > > > one and waste space. Do the performance gains outweigh this? (I'm > > > not terribly worried about the redundancy with the RAID 10 and > > > all). > > > > What performance gains are you referring to? > > The main performance benefit to having directories reside on their own > partition relates to file write/read access. It's very important to > have var on it's own seperate partition, specifically because it's > probably the most actively written to directory. OK. If you have a single physical hard drive or RAID array, the how will having /var on a separate partition give any benefit? Disk access still goes to the same hardware and is still limited by head seek times and rotational delays of the hardware. Having two seeks on the same partition or two seeks on separate partitions should not perform any differently. However if you have a single large partition then when you are writing data the FS drivers can optimise things. > Another little performance gain is the order in which you partition > your disks (the closer to the 0'th cylinder the faster the access time. This depends on the type of device. This is a general rule that doesn't always apply. But when it does apply it's not so small. 50% extra performance at the start of the disk is not uncommon. AFAIK I'm the only person to publish a benchmark program to measure this... > For instance, this is the order in which I usually go about > partitioning my drive (note: it varies depending on it i'm setting up a > workstation or a server, but they are similar). > >size: totalmem*2 (64mb = 128mb partition) > / > /tmp > > /usr > /var > /home Swap is often the most used partition. Root is probably the least. /tmp and /home are both candidates for the most used partition. Having things separate like this means that in many common usage situations you'll have the heads seeking across the entire disk all the time. Having a single partition could increase performance... > If I run out of room on /var/www or /var/cvs or something, I can stick > another disk in and mount that in its place instead. I used to get > worried about wasted space, but if you just over estimate a bit, you > should be fine with most of the partitions that don't grow (like /, > /tmp, /usr). And you just give the most space the the ones that can > grow. Now I find a nice partitioning scheme to be much more manageable > and the performance is very noticable. If sticking another disk in is so easy then why not just install lots of disks in a RAID array from the start? That'll get the best performance... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
On Saturday 23 June 2001 04:10, Nick Jennings wrote: > > > one and waste space. Do the performance gains outweigh this? (I'm > > > not terribly worried about the redundancy with the RAID 10 and > > > all). > > > > What performance gains are you referring to? > > The main performance benefit to having directories reside on their own > partition relates to file write/read access. It's very important to > have var on it's own seperate partition, specifically because it's > probably the most actively written to directory. OK. If you have a single physical hard drive or RAID array, the how will having /var on a separate partition give any benefit? Disk access still goes to the same hardware and is still limited by head seek times and rotational delays of the hardware. Having two seeks on the same partition or two seeks on separate partitions should not perform any differently. However if you have a single large partition then when you are writing data the FS drivers can optimise things. > Another little performance gain is the order in which you partition > your disks (the closer to the 0'th cylinder the faster the access time. This depends on the type of device. This is a general rule that doesn't always apply. But when it does apply it's not so small. 50% extra performance at the start of the disk is not uncommon. AFAIK I'm the only person to publish a benchmark program to measure this... > For instance, this is the order in which I usually go about > partitioning my drive (note: it varies depending on it i'm setting up a > workstation or a server, but they are similar). > >size: totalmem*2 (64mb = 128mb partition) > / > /tmp > > /usr > /var > /home Swap is often the most used partition. Root is probably the least. /tmp and /home are both candidates for the most used partition. Having things separate like this means that in many common usage situations you'll have the heads seeking across the entire disk all the time. Having a single partition could increase performance... > If I run out of room on /var/www or /var/cvs or something, I can stick > another disk in and mount that in its place instead. I used to get > worried about wasted space, but if you just over estimate a bit, you > should be fine with most of the partitions that don't grow (like /, > /tmp, /usr). And you just give the most space the the ones that can > grow. Now I find a nice partitioning scheme to be much more manageable > and the performance is very noticable. If sticking another disk in is so easy then why not just install lots of disks in a RAID array from the start? That'll get the best performance... -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Fri, Jun 22, 2001 at 03:17:12PM +0200, Russell Coker wrote: > > > looking for help, it will be used as an IMAP/SMTP machine. So, should > > I create a separate /var partition? I'm hesitant because I don't want > > to a) not create a large enough partition, or b) create too large of > > I suggest having your email stored on the same file system as /home. > Then you have all of your customer data on the same file system for easy > backup. Also it saves juggling space. > > > one and waste space. Do the performance gains outweigh this? (I'm not > > terribly worried about the redundancy with the RAID 10 and all). > > What performance gains are you referring to? > The main performance benefit to having directories reside on their own partition relates to file write/read access. It's very important to have var on it's own seperate partition, specifically because it's probably the most actively written to directory. Another little performance gain is the order in which you partition your disks (the closer to the 0'th cylinder the faster the access time. For instance, this is the order in which I usually go about partitioning my drive (note: it varies depending on it i'm setting up a workstation or a server, but they are similar). size: totalmem*2 (64mb = 128mb partition) / /tmp /usr /var /home If i'm setting up a webserver i'll usualy make a /var/www, and if i'm setting up a mailserver, i'll add a /var/spool/mail, and for development servers i'll even throw in a /var/cvs Sometimes, with a server I like to make /usr just 1gig or so, and make a /usr/local/ for custom scripts & stuff I compile from source. If I run out of room on /var/www or /var/cvs or something, I can stick another disk in and mount that in its place instead. I used to get worried about wasted space, but if you just over estimate a bit, you should be fine with most of the partitions that don't grow (like /, /tmp, /usr). And you just give the most space the the ones that can grow. Now I find a nice partitioning scheme to be much more manageable and the performance is very noticable. -- Nick Jennings
Re: disk partition schemes
On Fri, Jun 22, 2001 at 03:17:12PM +0200, Russell Coker wrote: > > > looking for help, it will be used as an IMAP/SMTP machine. So, should > > I create a separate /var partition? I'm hesitant because I don't want > > to a) not create a large enough partition, or b) create too large of > > I suggest having your email stored on the same file system as /home. > Then you have all of your customer data on the same file system for easy > backup. Also it saves juggling space. > > > one and waste space. Do the performance gains outweigh this? (I'm not > > terribly worried about the redundancy with the RAID 10 and all). > > What performance gains are you referring to? > The main performance benefit to having directories reside on their own partition relates to file write/read access. It's very important to have var on it's own seperate partition, specifically because it's probably the most actively written to directory. Another little performance gain is the order in which you partition your disks (the closer to the 0'th cylinder the faster the access time. For instance, this is the order in which I usually go about partitioning my drive (note: it varies depending on it i'm setting up a workstation or a server, but they are similar). size: totalmem*2 (64mb = 128mb partition) / /tmp /usr /var /home If i'm setting up a webserver i'll usualy make a /var/www, and if i'm setting up a mailserver, i'll add a /var/spool/mail, and for development servers i'll even throw in a /var/cvs Sometimes, with a server I like to make /usr just 1gig or so, and make a /usr/local/ for custom scripts & stuff I compile from source. If I run out of room on /var/www or /var/cvs or something, I can stick another disk in and mount that in its place instead. I used to get worried about wasted space, but if you just over estimate a bit, you should be fine with most of the partitions that don't grow (like /, /tmp, /usr). And you just give the most space the the ones that can grow. Now I find a nice partitioning scheme to be much more manageable and the performance is very noticable. -- Nick Jennings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
Kevin J. Menard, Jr. wrote: Hey Russell, Friday, June 22, 2001, 11:07:37 AM, you wrote: RC> What exactly will that save you from? If the root FS gets messed up then RC> having a separate /boot won't gain you much... I was thinking the other way around actually. If /boot were to get messed up, it wouldn't affect /. RC> I suggest creating /home/mail and linking /var/spool/mail to it. However RC> if you want decent performance for email you want to use Maildir. By RC> default maildir storage goes into user's home directories which solves RC> this issue. Well, I'll be using Cyrus IMAPd. Doesn't use Maildir, but does create separate folders per user. Thus, the spool is really not going to hold data much. However long it takes to rip data off incoming (using postfix) and send it out, or however long to hand it off to lmtpd and let cyrus deliver it. RC> If you have two partitions on the same physical media (in this case a RC> RAID-10) then expect to lose performance. If you make it all one large RC> partition then the file system drivers can optimise things more. Oh. Guess I didn't quite understand how disk I/O functioned. I figured something like /var, which will have a lot of synchronous writes, would get better performance outside of / or /home. RC> I recommend having a separate /home to limit the things that can go RC> wrong. I recommend leaving /var on the root file system unless you need RC> a lot of space in /var. Just from a performance point of view or for other reasons? RC> Also consider a separate file system for RC> /var/tmp and make /tmp a sym-linke to /var/tmp/tmp . Once again . . . just for stability? security? drives have come a long way, and with a RAID 10, would I be safe in doing this? Or should I just have a coulple gig / and the rest for /home? RC> RAID has no relevance to the issue of partitioning in this sense. Well, my point here was, with the RAID 10, I already have a pretty good amount of reliability, as if one drive fails, the system can still function. And with disks that are pretty reliable to begin with, I wasn't sure if the combination of all these would merit just one large / fs. Thanks again. Hm, This is interesting, I have almost always used separate partitions, such as /var, and it's saved my butt a couple times. If a log file starts to run away, which I've had happen a twice, it can't overflow the boundaries of the partition and crash the box, which it can if it's on /. I _always_ use a seprarate /home, so I can keep data in case I have to reinstall the OS, (successful intrustion attempt, etc.) and I've been using a /boot for no good reason. :o) The other benefit could, I've theorized, come from chrooting certain processes, If you leave them on a separate partition, and somehow someone exploits the partition, you can restore from your backup of the partition, without _too_ much difficulty. Just my opinion, and I'd welcome comments on the topic. ~duane
Re: disk partition schemes
On Friday 15 June 2001 16:13, Kevin J. Menard, Jr. wrote: > This system would be used mostly for web-hosting, so I was figuring > a large /home partition. Likewise only one or two kernels max, so I > figured a small /boot. And finally, and this is really where I'm Why do you need a separate partition for /boot? Why not just have it in the root fs? Problems with booting from partitions >2G were solved ages ago, your root file system should fit into 8G (although even that limit doesn't apply if your BIOS is new enough). > looking for help, it will be used as an IMAP/SMTP machine. So, should > I create a separate /var partition? I'm hesitant because I don't want > to a) not create a large enough partition, or b) create too large of I suggest having your email stored on the same file system as /home. Then you have all of your customer data on the same file system for easy backup. Also it saves juggling space. > one and waste space. Do the performance gains outweigh this? (I'm not > terribly worried about the redundancy with the RAID 10 and all). What performance gains are you referring to? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
Re: disk partition schemes
Kevin J. Menard, Jr. wrote: > Hey Russell, > > > Friday, June 22, 2001, 11:07:37 AM, you wrote: > > RC> What exactly will that save you from? If the root FS gets messed up then > RC> having a separate /boot won't gain you much... > > I was thinking the other way around actually. If /boot were to get messed up, > it wouldn't affect /. > > RC> I suggest creating /home/mail and linking /var/spool/mail to it. However > RC> if you want decent performance for email you want to use Maildir. By > RC> default maildir storage goes into user's home directories which solves > RC> this issue. > > Well, I'll be using Cyrus IMAPd. Doesn't use Maildir, but does create separate > folders per user. Thus, the spool is really not going to hold data much. > However long it takes to rip data off incoming (using postfix) and send it out, > or however long to hand it off to lmtpd and let cyrus deliver it. > > RC> If you have two partitions on the same physical media (in this case a > RC> RAID-10) then expect to lose performance. If you make it all one large > RC> partition then the file system drivers can optimise things more. > > Oh. Guess I didn't quite understand how disk I/O functioned. I figured > something like /var, which will have a lot of synchronous writes, would get > better performance outside of / or /home. > > RC> I recommend having a separate /home to limit the things that can go > RC> wrong. I recommend leaving /var on the root file system unless you need > RC> a lot of space in /var. > > Just from a performance point of view or for other reasons? > > RC> Also consider a separate file system for > RC> /var/tmp and make /tmp a sym-linke to /var/tmp/tmp . > > Once again . . . just for stability? security? > > >>>drives have come a long way, and with a RAID 10, would I be safe in >>>doing this? Or should I just have a coulple gig / and the rest for >>>/home? >>> > > RC> RAID has no relevance to the issue of partitioning in this sense. > > Well, my point here was, with the RAID 10, I already have a pretty good amount > of reliability, as if one drive fails, the system can still function. And with > disks that are pretty reliable to begin with, I wasn't sure if the combination > of all these would merit just one large / fs. > > Thanks again. > > Hm, This is interesting, I have almost always used separate partitions, such as /var, and it's saved my butt a couple times. If a log file starts to run away, which I've had happen a twice, it can't overflow the boundaries of the partition and crash the box, which it can if it's on /. I _always_ use a seprarate /home, so I can keep data in case I have to reinstall the OS, (successful intrustion attempt, etc.) and I've been using a /boot for no good reason. :o) The other benefit could, I've theorized, come from chrooting certain processes, If you leave them on a separate partition, and somehow someone exploits the partition, you can restore from your backup of the partition, without _too_ much difficulty. Just my opinion, and I'd welcome comments on the topic. ~duane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
On Friday 15 June 2001 16:13, Kevin J. Menard, Jr. wrote: > This system would be used mostly for web-hosting, so I was figuring > a large /home partition. Likewise only one or two kernels max, so I > figured a small /boot. And finally, and this is really where I'm Why do you need a separate partition for /boot? Why not just have it in the root fs? Problems with booting from partitions >2G were solved ages ago, your root file system should fit into 8G (although even that limit doesn't apply if your BIOS is new enough). > looking for help, it will be used as an IMAP/SMTP machine. So, should > I create a separate /var partition? I'm hesitant because I don't want > to a) not create a large enough partition, or b) create too large of I suggest having your email stored on the same file system as /home. Then you have all of your customer data on the same file system for easy backup. Also it saves juggling space. > one and waste space. Do the performance gains outweigh this? (I'm not > terribly worried about the redundancy with the RAID 10 and all). What performance gains are you referring to? -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: disk partition schemes
Hello Kevin, > should I create a separate /var Yes, you most definitely should. IMHO, whatever config you're going for, logs reside in /var by default in all the linux distros I've tried > used mostly for web-hosting > used as an IMAP/SMTP machine In your case, given that mail would resides by default in /var/spool - this would be another reason to create a separate /var partition. In fact, it wouldn't be bad to create another partition exclusive to /var/spool/mail. > don't want to a) not create a large enough partition > b) create too large of one and waste space Don't' worry, I learned too late that I should have completely read the Installation Guide for suggested debian partition schemes. /var/cache is where apt will store all the .deb files (I learned this the hard way as I was grabbing additional packages). If you'll probably want to run X-windows too, /var should at the very least be larger than 200MB to accommodate lots of .debs (I personally try to reserve at least 1GB of /var for servers and workstations). Good luck, Erik Abella
Re: disk partition schemes
Hello Kevin, > should I create a separate /var Yes, you most definitely should. IMHO, whatever config you're going for, logs reside in /var by default in all the linux distros I've tried > used mostly for web-hosting > used as an IMAP/SMTP machine In your case, given that mail would resides by default in /var/spool - this would be another reason to create a separate /var partition. In fact, it wouldn't be bad to create another partition exclusive to /var/spool/mail. > don't want to a) not create a large enough partition > b) create too large of one and waste space Don't' worry, I learned too late that I should have completely read the Installation Guide for suggested debian partition schemes. /var/cache is where apt will store all the .deb files (I learned this the hard way as I was grabbing additional packages). If you'll probably want to run X-windows too, /var should at the very least be larger than 200MB to accommodate lots of .debs (I personally try to reserve at least 1GB of /var for servers and workstations). Good luck, Erik Abella -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
