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: Recommended X.21 Cards ?
Hi, thanks for your hints. Bernd
privileges problem
while configuring dynamic virtual hosting (with mod_vhost_alias) on a new server i ran into this problem i create a new group named g(username) for each new virtual web, I set all user files to chmod 640 to avoid them to be read by another user my apache server runs as www-data so i need to add user www-data to each virtual web group to be able to serve its documents this all works fine but when I create a new virtual web, that means a new group, user and home directory and try to access its documents via http I get this error in the apache error.log Permission denied: /home/html/inko.sk/public_html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable everything works well after restarting the apache server, it looks like the running apache server doesn't know that the user it runs as (www-data) became a member of the new group created for the new virtual web is there a way to somehow refresh this info for the running process without restarting it? do you have another suggestion? If I have to restart apache every time I add a new server then I am on the beginning and usibng mod_vhost_alias didn't help at all. thanks Martin Dragun
Re: Recommended X.21 Cards ?
Hi, thanks for your hints. Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
privileges problem
while configuring dynamic virtual hosting (with mod_vhost_alias) on a new server i ran into this problem i create a new group named g(username) for each new virtual web, I set all user files to chmod 640 to avoid them to be read by another user my apache server runs as www-data so i need to add user www-data to each virtual web group to be able to serve its documents this all works fine but when I create a new virtual web, that means a new group, user and home directory and try to access its documents via http I get this error in the apache error.log Permission denied: /home/html/inko.sk/public_html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable everything works well after restarting the apache server, it looks like the running apache server doesn't know that the user it runs as (www-data) became a member of the new group created for the new virtual web is there a way to somehow refresh this info for the running process without restarting it? do you have another suggestion? If I have to restart apache every time I add a new server then I am on the beginning and usibng mod_vhost_alias didn't help at all. thanks Martin Dragun -- 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: Re[6]: disk partition schemes
On Saturday 23 June 2001 03:35, Kevin J. Menard, Jr. wrote: > >> I was thinking the other way around actually. If /boot were to get > >> messed up, it wouldn't affect /. > > I guess I'm off here. By getting messed up, I mean more by say a > sudden jolt in the power supply (of course, I do have a line > conditioning UPS) and mess up the partition table or something. That is something to consider, and is a good reason for having /home and /var/separate from the root FS. The root FS then gets hardly any writes and is unlikely to have such things. It's easy to imagine situations where a FS is corrupted badly enough that programs can't be run from it, but which can be fully recovered by fsck. One thing I have considered is making the root FS mounted synchronously to reduce such risks. However /boot is the least written partition you are likely to have. > RC> Having /home and /tmp on separate devices to / gives some security > RC> benefits by limiting the ability to produce hard links. Hard > linking RC> /etc/passwd or /etc/shadow to a name under /tmp or the > user's home RC> directory has been step 1 of a number of security > attacks... > > I didn't realize hard links couldn't cross partition boundaries. I > tend to just use symlinks anyway. Hard links are just two directory entries with the same Inode number. Inode numbers only apply within the same file system. > RC> How will one partition or two partitions affect reliability? Disk > RC> failures tend to be boolean things, if a disk starts dieing then > all data RC> seems to rapidly disappear from it. So in you don't have > RAID then RC> having separate partitions is unlikely to save you. > > Once again, I guess I was thinking messed up partition tables or > something. Perhaps my logic was flawed. The most likely type of messed up partition table you are likely to see is corruption or a read error on the first sector. This is totally fatal to all partitions. The only solution is to make a note of the sizes of all partitions so you can recreate the partition table. -- 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: Image disk for debian
On Wed, Jun 20, 2001 at 04:10:55PM +0200, Teun Vink wrote: > > Is there a way of selecting packages and storing them in a flat text > > file, that debian uses to reference in the installation procedure. > > dpkg --get-selections > file > dpkg --set-selections < file > > should do the trick if you only want to store package names... if you want the status of all packages (including purged/removed packages) to be included, then use: dpkg --get-selections "*" > file without the "*", --get-selections only outputs the status of installed packages. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
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: Re[6]: disk partition schemes
On Saturday 23 June 2001 03:35, Kevin J. Menard, Jr. wrote: > >> I was thinking the other way around actually. If /boot were to get > >> messed up, it wouldn't affect /. > > I guess I'm off here. By getting messed up, I mean more by say a > sudden jolt in the power supply (of course, I do have a line > conditioning UPS) and mess up the partition table or something. That is something to consider, and is a good reason for having /home and /var/separate from the root FS. The root FS then gets hardly any writes and is unlikely to have such things. It's easy to imagine situations where a FS is corrupted badly enough that programs can't be run from it, but which can be fully recovered by fsck. One thing I have considered is making the root FS mounted synchronously to reduce such risks. However /boot is the least written partition you are likely to have. > RC> Having /home and /tmp on separate devices to / gives some security > RC> benefits by limiting the ability to produce hard links. Hard > linking RC> /etc/passwd or /etc/shadow to a name under /tmp or the > user's home RC> directory has been step 1 of a number of security > attacks... > > I didn't realize hard links couldn't cross partition boundaries. I > tend to just use symlinks anyway. Hard links are just two directory entries with the same Inode number. Inode numbers only apply within the same file system. > RC> How will one partition or two partitions affect reliability? Disk > RC> failures tend to be boolean things, if a disk starts dieing then > all data RC> seems to rapidly disappear from it. So in you don't have > RAID then RC> having separate partitions is unlikely to save you. > > Once again, I guess I was thinking messed up partition tables or > something. Perhaps my logic was flawed. The most likely type of messed up partition table you are likely to see is corruption or a read error on the first sector. This is totally fatal to all partitions. The only solution is to make a note of the sizes of all partitions so you can recreate the partition table. -- 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]
