Re: Re: [ANNOUNCE] PostgreSQL 7.0 a success
От | Giles Lean |
---|---|
Тема | Re: Re: [ANNOUNCE] PostgreSQL 7.0 a success |
Дата | |
Msg-id | 17763.959250537@nemeton.com.au обсуждение исходный текст |
Список | pgsql-general |
On Thu, 25 May 2000 06:21:10 +0200 (MEST) Jan Wieck wrote: > Could you please explain this to some detail? From the MySQL 3.23.16-alpha documentation: For now the only allowed RAID_TYPE is STRIPED ... If you specify RAID_TYPE=STRIPED for a MyISAM table, MyISAM will create RAID_CHUNKS sub-directories named 00, 01, 02 in the database directory. In each of these directories MyISAM will create an table_name.MYD. When writing data to the data file, the RAID handler will map the first RAID_CHUNKSIZE *1024 bytes to the first file, the next RAID_CHUNKSIZE *1024 bytes to the next file and so on. I wouldn't call that RAID; it's missing "redundant". Being able to exercise some control over the physical location of data to balance I/O isn't a bad idea, but I doubt that it need be mixed up with RAID concepts. > Only databases using RAW devices, on a per-OS specific > implementation, could implement RAID similar behaviour AFAIK. Hmm? From some high level viewpoint RAID is spreading data around multiple locations with sufficient redundancy that if one of those locations disappears, the data is still able to be accessed. I don't see how blocks-on-filesystems are inherently so different to blocks-on-raw-devices that this redundancy is not at least theoretically possible. Am I missing something? My immediate reaction though is that RAID is better either done in hardware, or integrated with the OS kernel where it is easier to get real status information from devices. Trying to build an application that can cope with filesystems disappearing out from under it would be very challenging, particularly for an application that has to be portable. Regards, Giles
В списке pgsql-general по дате отправления: