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: 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]
Re[6]: disk partition schemes
Hey Russell, Friday, June 22, 2001, 7:22:41 PM, you 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. RC> OK. So you want Cyrus storage on the file system used for user data. That's the idea. Let's see if I can get it to work :-P RC> IFF you have separate physical hardware for the different file systems RC> that will be true. However you only have one physical device (the RAID RC> device) so this will not be a benefit. Ahh, ok. Thanks for correcting me here. 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. RC> Having /tmp and /home on separate devices to the root FS limits the RC> ability of hostile users to perform such attacks. So I see. >> 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? RC> Security as described above and stability regarding issues of lack of RC> space and/or Inodes. Ok. 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. -- Kevin
Re[6]: disk partition schemes
Hey Russell, Friday, June 22, 2001, 7:22:41 PM, you 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. RC> OK. So you want Cyrus storage on the file system used for user data. That's the idea. Let's see if I can get it to work :-P RC> IFF you have separate physical hardware for the different file systems RC> that will be true. However you only have one physical device (the RAID RC> device) so this will not be a benefit. Ahh, ok. Thanks for correcting me here. 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. RC> Having /tmp and /home on separate devices to the root FS limits the RC> ability of hostile users to perform such attacks. So I see. >> 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? RC> Security as described above and stability regarding issues of lack of RC> space and/or Inodes. Ok. 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. -- Kevin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
