Re: [HACKERS] [hackers]development suggestion needed - Mailing list pgsql-hackers

From Malcolm Beattie
Subject Re: [HACKERS] [hackers]development suggestion needed
Date
Msg-id E12944k-0004gn-00@sable.ox.ac.uk
Whole thread Raw
In response to Re: [HACKERS] [hackers]development suggestion needed  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: [HACKERS] [hackers]development suggestion needed
List pgsql-hackers
Don Baccus writes:
> At 12:21 AM 1/14/00 -0400, The Hermit Hacker wrote:
> 
> >All the major OSs out there have "disk management tools" that allow you to
> >build "large file systems" out of smaller ones... Solaris has DiskSuite,
> >FreeBSD has vinum, Linux has ??... why are we looking/investigating adding
> >a level of complexity to PostgreSQL to handle something that, as far as I
> >know, each of the OSs out there already has a way of dealing with?
> 
> If the resident OS can handle the issue, sure, it is worth investigating.
> Linux today does not (at least, the one I'm running).

Linux has software raid (often called "md") with most of the usual
bells and whistles (RAID0, RAID1, RAID5, RAID0+1, hot spares,
background reconstruction). You can patch in LVM (logical volume
management) although the distributions of which I am aware don't ship
it ready-patched. That's the equivalent of Digi^H^H^H^HTru64 UNIX LSM
and AIX and so on have similar things. Basically, join together
physical disk units into logical block devices with additions being
possible on the fly. If you put an ext2 filesystem on one of those,
then you can dynamically resize it with e2resize, although that is not
completely production quality yet and last I heard you could currently
only increase the filesystem size on the fly and not decrease it. ISTR
the competition tend only to allow increase and not shrink but the
ext2 one is designed to allow shrink too. The complexity isn't so much
in the basics ("simply" throw in more block groups and be carefuly
about atomicity if the system is live); it's in stuff like making sure
that the system is robust against fragmentation, goal allocation needs
tweaking (I think) and how you gather together admin information about
where all the bits are. If you break apart the separate disks of a
live filesystem, it's nice to know where all the bits go.

Even with all that underlying stuff, it's *still* important for higher
level configuration at the database level to be possible. Even if from
the theoretical point of view it's all one big page space, it matters
a great deal in practice to be able to spread different bits out over
different table spaces/volumes/files/block devices/whatever.

I think that means I'm in violent agreement with you on the db side
but this reply does give me a chance to point out that Linux isn't
missing the functionality you haven't noticed in it :-).

--Malcolm

-- 
Malcolm Beattie <mbeattie@sable.ox.ac.uk>
Unix Systems Programmer
Oxford University Computing Services


pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] [hackers]development suggestion needed
Next
From: Karel Zak - Zakkr
Date:
Subject: locale vs. regress