Very rough storage validation matrix draft
Al Dunsmuir
al.dunsmuir at sympatico.ca
Mon Mar 17 19:04:58 UTC 2014
On Monday, March 17, 2014, 12:13:38 PM, Adam Williamson wrote:
> On Mon, 2014-03-17 at 10:25 -0400, Al Dunsmuir wrote:
>> On Monday, March 17, 2014, 4:14:50 AM, Kamil Paral wrote:
>> > I can't either, and even if I did, I don't think it would justify
>> > the result number explosion. Storage is storage, arch is usually completely irrelevant.
>>
>> > When we're at it, why do we have both i686 and x86_64 at "Device
>> > tests"? A single results column for x86 should be enough. Same reasoning.
>>
>> In the past, some filesystems have had issues handling 64-bit inodes
>> in 32-bit architectures. User data is too important to make an
>> assumption that these no longer will occur.
> Device tests are not filesystem tests, though.
> Could you provide some references to these issues?
XFS has had bugs related to this which showed up with large disks
and large numbers of files.
Recent example:
NFS + large XFS fs sometimes fails uncached lookups for client when inode number >2^32 on 32-bit computers
https://bugzilla.redhat.com/show_bug.cgi?id=1003546
Application code had some problems. For example, Adobe code (not that
we really care about closed source packages from outside Fedora).
Bug: Adobe Reader 64-bit inode problem
http://forums.adobe.com/message/4721987
> With either set of tests, though, I don't see that any 'user data' is
> involved: in each case the only partitions we're creating or touching
> are new ones with no user data involved. Even if one of the filesystems
> we create might suffer from a bug further down the line, I don't think
> any of these tests would catch it, would they?
> --
> Adam Williamson
Likely not a significant risk, but it seems useful to me to
explicitly identify the architecture that has been tested, so IF a
problem does arise in the future that information is freely available.
Al
More information about the test
mailing list