On Wed, 12 Jan 2000, Gadi Oxman wrote:
> As far as I know, we took care not to poke into the buffer cache to
> find clean buffers -- in raid5.c, the only code which does a find_buffer()
> is:
yep, this is still the case. (Sorry Stephen, my bad.) We will have these
problems once we try to eliminate the current copying overhead.
Nevertheless there are bad (illegal) interactions between the RAID code
and the buffer cache, i'm cleaning up this for 2.3 right now. Especially
the reconstruction code is a rathole. Unfortunately blocking
reconstruction if b_count == 0 is not acceptable because several
filesystems (such as ext2fs) keep metadata caches around (eg. the block
group descriptors in the ext2fs case) which have b_count == 1 for a longer
time.
If both power and a disk fails at once then we still might get local
corruption for partially written RAID5 stripes. If either power or a disk
fails, then the Linux RAID5 code is safe wrt. journalling, because it
behaves like an ordinary disk. We are '100% journal-safe' if power fails
during resync. We are also 100% journal-safe if power fails during
reconstruction of failed disk or in degraded mode.
the 2.3 buffer-cache enhancements i wrote ensure that 'cache snooping' and
adding to the buffer-cache can be done safely by 'external' cache
managers. I also added means to do atomic IO operations which in fact are
several underlying IO operations - without the need of allocating a
separate bh. The RAID code uses these facilities now.
Ingo
