Yes, luckily it does - so no lasting damage is/was caused. Needless to say though, until the fault was pinned down to the kernel change, there was a serious moment of panic about the possible loss of 70TiB + of data!
According to the person from the link in my first post, the problem didn't appear to exist in 2.6.32-39 but was there in 2.6.32-41; but I encountered it in 2.6.32-40. They were, however as far as I can tell, using a vanilla Debian; but assuming these kernel numbers tally-up with Ubuntu's, it appears the problem crept in somewhere in the 2.6.32-40 release.
Looking in the Debian kernel change-log, I wouldn't mind betting this would have had something to do with it:
[ Ben Hutchings ]
* Add longterm releases 2.6.32.47 and 2.6.32.48, including:
.....
- md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.
.....
Unfortunately this is a very busy production machine and I have very limited time to pin point the issue further.
Yes, luckily it does - so no lasting damage is/was caused. Needless to say though, until the fault was pinned down to the kernel change, there was a serious moment of panic about the possible loss of 70TiB + of data!
According to the person from the link in my first post, the problem didn't appear to exist in 2.6.32-39 but was there in 2.6.32-41; but I encountered it in 2.6.32-40. They were, however as far as I can tell, using a vanilla Debian; but assuming these kernel numbers tally-up with Ubuntu's, it appears the problem crept in somewhere in the 2.6.32-40 release.
Looking in the Debian kernel change-log, I wouldn't mind betting this would have had something to do with it:
[ Ben Hutchings ]
* Add longterm releases 2.6.32.47 and 2.6.32.48, including:
.....
- md: Fix handling for devices from 2TB to 4TB in 0.90 metadata.
.....
Unfortunately this is a very busy production machine and I have very limited time to pin point the issue further.