Re: Re[4]: disk partition schemes

2001-06-22 Thread Russell Coker
On Friday 22 June 2001 17:33, Kevin J. Menard, Jr. 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 /.

As /boot almost never gets written to I think it's the least likely 
partition to get seriously stuffed.

> 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.

OK.  So you want Cyrus storage on the file system used for user data.

> 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.

IFF you have separate physical hardware for the different file systems 
that will be true.  However you only have one physical device (the RAID 
device) so this will not be a benefit.

> 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?

Having /home and /tmp on separate devices to / gives some security 
benefits by limiting the ability to produce hard links.  Hard linking 
/etc/passwd or /etc/shadow to a name under /tmp or the user's home 
directory has been step 1 of a number of security attacks...

Having /tmp and /home on separate devices to the root FS limits the 
ability of hostile users to perform such attacks.

> 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?

Security as described above and stability regarding issues of lack of 
space and/or Inodes.

> >> 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.

How will one partition or two partitions affect reliability?  Disk 
failures tend to be boolean things, if a disk starts dieing then all data 
seems to rapidly disappear from it.  So in you don't have RAID then 
having separate partitions is unlikely to save you.

-- 
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[4]: disk partition schemes

2001-06-22 Thread Russell Coker

On Friday 22 June 2001 17:33, Kevin J. Menard, Jr. 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 /.

As /boot almost never gets written to I think it's the least likely 
partition to get seriously stuffed.

> 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.

OK.  So you want Cyrus storage on the file system used for user data.

> 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.

IFF you have separate physical hardware for the different file systems 
that will be true.  However you only have one physical device (the RAID 
device) so this will not be a benefit.

> 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?

Having /home and /tmp on separate devices to / gives some security 
benefits by limiting the ability to produce hard links.  Hard linking 
/etc/passwd or /etc/shadow to a name under /tmp or the user's home 
directory has been step 1 of a number of security attacks...

Having /tmp and /home on separate devices to the root FS limits the 
ability of hostile users to perform such attacks.

> 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?

Security as described above and stability regarding issues of lack of 
space and/or Inodes.

> >> 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.

How will one partition or two partitions affect reliability?  Disk 
failures tend to be boolean things, if a disk starts dieing then all data 
seems to rapidly disappear from it.  So in you don't have RAID then 
having separate partitions is unlikely to save you.

-- 
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[4]: disk partition schemes

2001-06-22 Thread Kevin J. Menard, Jr.
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.

-- 
 Kevin




Re[4]: disk partition schemes

2001-06-22 Thread Kevin J. Menard, Jr.

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.

-- 
 Kevin


--  
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]