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