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
