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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
