On Tue, Mar 02, 2010 at 02:04:47AM -0800, Michael Evans wrote:
On Mon, Mar 1, 2010 at 11:36 PM, Luca Berra <bluca@xxxxxxxxxx> wrote:
On Tue, Mar 02, 2010 at 04:01:00PM +1100, Neil Brown wrote:
Disk 1 contains A and B in the correct order, it is missing C and B' but
we
dont care, app should be able to recover from a crash
Disk 2 contains A and B', but they are wrongly ordered because C is
missing
If in the above case A and C are data blocks and B contains a journal
related to A and C, booting from disk 2 could result in inconsistent
data.
can the above really happen?
would using barriers remove the above concern?
am i missing something else?
These is no inconsistency here that a filesystem would not equally expect
from a single device.
After the crash-while-writing B', it should expect to see either B or B',
and it does, depending on which device is primary.
Nothing to see here.
I will try to explain better,
the problem is not related to the confusion between B or B'
the problem is that on one disk we have B' _without_ C.
You're demanding full atomic commits; this is precisely what journals
and /barriers/ are for.
Are you are bypassing them in a quest for performance and paying for
it on crashes?
Or is this a hardware bug?
Or is it some glitch in the block device layering leading to barrier
requests not being honored?
I just asked for confirmation that with /barriers/ the scenario above
would not happen.
L.
--
Luca Berra -- bluca@xxxxxxxxxx
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
