Re: [HACKERS] [hackers]development suggestion needed
От | Malcolm Beattie |
---|---|
Тема | Re: [HACKERS] [hackers]development suggestion needed |
Дата | |
Msg-id | E12944k-0004gn-00@sable.ox.ac.uk обсуждение исходный текст |
Ответ на | Re: [HACKERS] [hackers]development suggestion needed (Don Baccus <dhogaza@pacifier.com>) |
Ответы |
Re: [HACKERS] [hackers]development suggestion needed
(Don Baccus <dhogaza@pacifier.com>)
|
Список | 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 по дате отправления: