[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VA Pics



> Well, the usual would be to have a seperate partition for /var, and
> possibly /usr/local (that probably is a good idea - we could put stuff

I never liked splitting /usr/local off from /usr.  In this case it *could*
be beneficial.  If we go this route I'd throw 1.5GB into /usr and 1GB into
/usr/local for starters.  We'd have to make a habit of using
/usr/local/src and not /usr/src which we should be doing anyway.

> Perhaps a seperate partition for our Web root and static HTML pages.

No real need.

> Does MySQL store its data in /var?  Postgres does when you use the RPM. 
> Not sure how good an idea that is.

No.  MySQL defaults to using ./mysql/data
I'll take care of the mysql install once the box is up, but I want to
maintain that structure and just softlink data to the partition we want.
The data will definately need to reside on a partition other than the
MySQL execs.

> you're now saying that we're going to store the article text in the DB. 
> That would make a HUGE /var, or whever the DB is stored.

Yes... it will get large.

> Won't we also be storing the text in static HTML format?  If so, I'm not
> sure if 9GB is gonna be enough for very long.  :-)

It'll be enough for a while, but not forever.  May come sooner than I
expect which is why we need to plan this partitioning for future scaling.
The logical next step (easiest next step) from RAID-1 is RAID-10 (striping
across mirrored sets) which is still doable entirely in software.  2.2.0
is going to make software raid MUCH easier... and will even allow for
RAID5.  Once we go beyond 2 disks we're going to need to decide whether to
go to RAID-10 or RAID-5.  RAID-5 gives more space for the buck with almost
as much reliability as RAID-10.  If we go RAID-10 we're talking about
doubling partition sizes with expansion and each expansion will need to
take place in 2-drive increments... of which we only have enough space for
1 expansion in that case... giving us a max raided set of 18GB.  

Also... we'll want to re-adjust partition sizes either way when we
expand... we won't need 3GB in /usr... we'll want to take that 1.5 and
scale it back to 750MB or 1GB per raid set giving us 1.5 or 2GB total when
at RAID-10.  5GB in /home (or /export) will be good to double at that
point since thats where we'll be cramped when we get cramped.  By that
time we'll be at kernel 2.2 and RAID growing should be simple... making
RAID-10 attractive, but we'll eventually want to go RAID-5 either way
which will require a huge system overhaul (pray to god we have the IBM box
at that point).

Enough spouting on that for now...

> And then there's the ht://dig DB.  Perhaps it should be seperate too, I
> dunno.

I think having it on the same partition as the DB's and HTML will be OK.
Then again... maybe you do split the DB tables off from the static HTML
and ht://dig indexes... could cause fewer headaches on down the road...

If we're going to split that out I'd say we impliment the Solaris style
/export dir... you have /home, /apache (or /httpd or /web - whatever),
/cvs, /db, and /ftp all under /export.  Then you make /export,
/export/apache, and /export/db seperate partition mount points - let
/exports mount partition handle ftp, cvs, and home, and break out web & db
stuff.  Then you softlink /home to /export/home, etc.  And you can
softlink /home/apache to /export/apache if you like to see that stuff
under /home as your used too.

Actually... thanks for pointing this out Micah... I like the above
structure a lot.  Could provide us with a LOT of flexibility and a LOT
less headaches down the road.  Thats got my vote.  Anyone else like it?
If so lets work on formulating exact sizes of the above partitions... for
starters I'd say:

/		384 MB
/var		512 MB
/usr		1536MB
/usr/local	1024MB
/export		1024MB
/export/apache	2048MB
/export/db	2560MB
swap		128 MB

May be able to trim /usr down to 1024MB and bump /export up to 1536MB...
if we could do that it'd be much better.

> We're *this* close to 2.2.0 - why not just use it?  And how is VAR's
> kernel special?

Yeah... what's 'special' about it?

Jason