> Hi Steve;
>
> Several issues are coming up in debugging the RAID5
> and XFS issue(s). We will try this patch, but there are
> larger issues as well one of our engineers flushed out
> with Martin and Neils' help. However, this will solve
> part of them.
>
> There is still the issue of doing 512-byte writes and
> RAID 5 only does 1024. We are working on it with Neil
> and Martin with two of our engineers: Danny Cox (who sent
> this email), dcox@xxxxxxxxxx; and Robert Lasirona,
> rlasirona@xxxxxxxxxxx See the email below.
>
> Danny sent a patch to allow mkfs.xfs and mounting after
> play well while it is resyncing that we are trying now
> and will send on to the list.
>
> BTW, why are 512-byte writes done?
>
> thanks, Scott
>
512 byte writes are done by XFS because we have some metadata which is always
512 bytes long - there are 4 fields at the head of each allocation group which
are fixed at this size. The superblock and some headers for free block and
inode trees.
Because of the transactional nature of xfs, there are conceivably cases
where one chunk of 512 bytes must be written to disk (because it is at
the tail of the log and we need more log space), and the other 512 bytes
in the same 1K chunk must not be (because it is modified in memory and
not written to disk in the log yet).
Having said all that, I am not totally sure how it fits in with this:
SSmyth@xxxxxxxxxx said:
>> Raid 5 resync is done in "multiples of 1K", but XFS appears to need
>> 512-byte resyncs as the base unit. Sorry for the terse explanation
>> that probably seemed unclear.
I have not looked at the raid5 code, so I don't know at what level it
is doing the resync.
Steve
|